cue sheet file generation

[GoogleCodeExporter]

it would be nice, if rubyripper could generate a cue sheet file optionally.

Original issue reported on code.google.com by oliver....@gmail.com on 7 Oct 2007 at 5:04

[GoogleCodeExporter]

I've started a while ago with coding basic CUE sheet support (search in 
rr_lib.rb). 
I personally don't see much benefit in having them. This differs when the album 
is 
ripped to one file, but rubyripper doesn't currently allow this.

Anyway, when I code support for them, I'd like to test the result. Can anyone 
list 
some linux programs which support a cue sheet? So I can at least test if mine 
work ;)

Original comment by rubyripp...@gmail.com on 8 Oct 2007 at 7:52

• Changed state: Accepted

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I used EAC on windows to rip the CD to one file, encoded it to wavpack or flac 
and
put the cuesheet in the wv / flac file. But now I'm trying to avoid windows and
looking for an alternative on linux.

What happens to the gaps when I rip a CD with rubyripper? Are they appended to 
(or
preserved at) the end of the track? Most of the time I'm listening to whole 
albums
and I would like to preserve the gaps (silence). I also would like to make an 
exact
copy of the original CD from the ripped file(s).

you can write a TOC with cdrdao and convert it to CUE with cueconvert (from 
cuetools)

Original comment by oliver....@gmail.com on 9 Oct 2007 at 12:36

[GoogleCodeExporter]

I think cdparanoia automatically set the gap at the end of the previous track. 
I've 
never seen cdparanoia report any difference between the last sector of the 
previous 
(+1) and the starting sector of the next.

If anyone has a disc that has gaps between tracks, please give me the output of 
`cdparanoia -Q`

Original comment by rubyripp...@gmail.com on 9 Oct 2007 at 3:52

[GoogleCodeExporter]

Dire Straits - Money for Nothing 

cdparanoia -Q

Table of contents (audio tracks only):
track        length               begin        copy pre ch
===========================================================
  1.    25972 [05:46.22]       33 [00:00.33]    no   no  2
  2.    18078 [04:01.03]    26005 [05:46.55]    no   no  2
  3.    20545 [04:33.70]    44083 [09:47.58]    no   no  2
  4.    15817 [03:30.67]    64628 [14:21.53]    no   no  2
  5.    36815 [08:10.65]    80445 [17:52.45]    no   no  2
  6.    26710 [05:56.10]   117260 [26:03.35]    no   no  2
  7.    15793 [03:30.43]   143970 [31:59.45]    no   no  2
  8.    18607 [04:08.07]   159763 [35:30.13]    no   no  2
  9.    26283 [05:50.33]   178370 [39:38.20]    no   no  2
 10.    53960 [11:59.35]   204653 [45:28.53]    no   no  2
 11.    18455 [04:06.05]   258613 [57:28.13]    no   no  2
 12.    21730 [04:49.55]   277068 [61:34.18]    no   no  2
TOTAL  298765 [66:23.40]    (audio only)

cdrdao --read-toc / cueconvert

CATALOG 0042283641921

FILE "data.wav" WAVE
TRACK 01 AUDIO
PREGAP 00:00:33
INDEX 00 00:00:-33
INDEX 01 00:00:00

TRACK 02 AUDIO
INDEX 01 05:46:22

TRACK 03 AUDIO
INDEX 00 09:46:40
INDEX 01 09:47:25

TRACK 04 AUDIO
INDEX 00 14:20:02
INDEX 01 14:21:20

TRACK 05 AUDIO
INDEX 00 17:51:22
INDEX 01 17:52:12

TRACK 06 AUDIO
INDEX 00 26:01:15
INDEX 01 26:03:02

TRACK 07 AUDIO
INDEX 01 31:59:12

TRACK 08 AUDIO
INDEX 01 35:29:55

TRACK 09 AUDIO
INDEX 00 39:37:12
INDEX 01 39:37:62

TRACK 10 AUDIO
INDEX 01 45:28:20

TRACK 11 AUDIO
INDEX 01 57:27:55

TRACK 12 AUDIO
INDEX 00 61:32:65
INDEX 01 61:33:60

Original comment by oliver....@gmail.com on 9 Oct 2007 at 4:16

[GoogleCodeExporter]

you can generate .cue files with cuegen too, but cdrdao is more likely to be
installed on a linux box by default :)

anyway, you can use audacious, it is able to play music via cue sheets, but it's
really buggy in 1.3, and i haven't had the opportunity to test 1.4 yet

http://boards.nenolod.net/viewtopic.php?f=5&t=848

it seems to be less buggy with wav or flac, but if you want accurate result, 
you have
to run foobar2k in wine ;) (audacious seems to screw up track beginnings and 
ends -
again, in version 1.3)

they say amarok is also able to handle cue files but it never worked for me

if you add cuesheet support, then you also have to add a toggle to rip cd into 
single
or multiple files. if single file is chosen, cuesheet is generated, else not. it
shouldn't be that hard, it's just to use or not to use the -B flag in 
cdparanoia :)

the next step would be to generate cuesheet according to freedb or cdtext info
(PERFORMER, TITLE etc. fields), but we'll talk about this when initial support 
is
available ;)

Original comment by asdfasdf...@freemail.hu on 11 Nov 2007 at 10:55

[GoogleCodeExporter]

Adding an option for a single file wouldn't be too hard. Provided that it uses 
the 
same routine. But people probably don't want 2 temporary wav files of 500-800 
MB in 
size. Besides, it can be frustrating if only one read error was found and the 
whole 
disc has to be ripped again.

So somehow the rip has to be done in different less large chunks. This requires 
parsing the wav container in turn. This is to correct the overhead when joining 
the 
wav-files together. Then the correction mechanism should also be changed to 
only 
compare part of the master file. The reporting of the position should stay 
intact 
meanwhile.

So while creating the cue-sheet file isn't so hard. Difficulties arise in 
implementing the consequences.

Original comment by rubyripp...@gmail.com on 12 Nov 2007 at 10:25

[GoogleCodeExporter]

yeah after posting i also have been thinking about this. well, you know, this 
would
be a great improvement, the correction mechanism would be more similar to 
EAC's. rr
would have to check small pieces of the rip, blocks or whatever, but i have no 
damn
clue how this style of error checking could be done via cdparanoia (if at 
all)...

Original comment by asdfasdf...@freemail.hu on 12 Nov 2007 at 10:30

[GoogleCodeExporter]

This is possible because cdparanoia supports ripping from sector to sector. But 
going from track-based ripping to sector-based requires in effect to rewrite 
large 
parts of the SecureRip class. The very heart of the program. 

I've done a few trials at this before, but until now the added complexity seems 
to 
be too much to implement a working concept in a day or two.

Original comment by rubyripp...@gmail.com on 12 Nov 2007 at 10:39

[GoogleCodeExporter]

yepp, it's supposed to be really complex and difficult to achieve, but if you
succeed, rr could be the ultimate ripper on linux/unix (it's on it's way 
already;)

Original comment by asdfasdf...@freemail.hu on 13 Nov 2007 at 12:00

[GoogleCodeExporter]

Just a note that I too would love to see both cue sheets and the option to rip 
to one
large file.

In the world where 1 terabyte disks are becoming standard (and 250 on
laptops)....large temp files aren't that big a deal btw.  Although if they can 
be
avoided even better.

Original comment by samsli...@gmail.com on 20 Nov 2007 at 8:13

[GoogleCodeExporter]

Just installed the latest version of RubyRipper and I am very impressed.

This is the only feature that I feel is lacking. For me adding this feature 
would do
away with wine and EAC.

In term of the GUI all you would have to do is add a option under the "Create 
m3u
playlist" called "Create cue-sheet". Then you could have it output and 
cue-sheet like
this one for example.

REM GENRE "Alt. Rock, Grunge"
REM DATE 1992
REM DISCID A80FCF0E
REM COMMENT "ExactAudioCopy v0.95b4"
PERFORMER "Pearl Jam"
TITLE "Ten"
FILE "Pearl Jam - Ten\01 - Once.wav" WAVE
  TRACK 01 AUDIO
    TITLE "Once"
    PERFORMER "Pearl Jam"
    INDEX 01 00:00:00
FILE "Pearl Jam - Ten\02 - Even Flow.wav" WAVE
  TRACK 02 AUDIO
    TITLE "Even Flow"
    PERFORMER "Pearl Jam"
    INDEX 01 00:00:00
FILE "Pearl Jam - Ten\03 - Alive.wav" WAVE
  TRACK 03 AUDIO
    TITLE "Alive"
    PERFORMER "Pearl Jam"
    INDEX 01 00:00:00
FILE "Pearl Jam - Ten\04 - Why Go.wav" WAVE
  TRACK 04 AUDIO
    TITLE "Why Go"
    PERFORMER "Pearl Jam"
    INDEX 01 00:00:00
FILE "Pearl Jam - Ten\05 - Black.wav" WAVE
  TRACK 05 AUDIO
    TITLE "Black"
    PERFORMER "Pearl Jam"
    INDEX 01 00:00:00
FILE "Pearl Jam - Ten\06 - Jeremy.wav" WAVE
  TRACK 06 AUDIO
    TITLE "Jeremy"
    PERFORMER "Pearl Jam"
    INDEX 01 00:00:00
FILE "Pearl Jam - Ten\07 - Oceans.wav" WAVE
  TRACK 07 AUDIO
    TITLE "Oceans"
    PERFORMER "Pearl Jam"
    INDEX 01 00:00:00
FILE "Pearl Jam - Ten\08 - Porch.wav" WAVE
  TRACK 08 AUDIO
    TITLE "Porch"
    PERFORMER "Pearl Jam"
    INDEX 01 00:00:00
FILE "Pearl Jam - Ten\09 - Garden.wav" WAVE
  TRACK 09 AUDIO
    TITLE "Garden"
    PERFORMER "Pearl Jam"
    INDEX 01 00:00:00
FILE "Pearl Jam - Ten\10 - Deep.wav" WAVE
  TRACK 10 AUDIO
    TITLE "Deep"
    PERFORMER "Pearl Jam"
    INDEX 01 00:00:00
FILE "Pearl Jam - Ten\11 - Release.wav" WAVE
  TRACK 11 AUDIO
    TITLE "Release"
    PERFORMER "Pearl Jam"
    INDEX 01 00:00:00
FILE "Pearl Jam - Ten\12 - Alive [Live].wav" WAVE
  TRACK 12 AUDIO
    TITLE "Alive [Live]"
    PERFORMER "Pearl Jam"
    INDEX 01 00:00:00
FILE "Pearl Jam - Ten\13 - Wash.wav" WAVE
  TRACK 13 AUDIO
    TITLE "Wash"
    PERFORMER "Pearl Jam"
    INDEX 01 00:00:00
FILE "Pearl Jam - Ten\14 - Dirty Frank.wav" WAVE
  TRACK 14 AUDIO
    TITLE "Dirty Frank"
    PERFORMER "Pearl Jam"
    INDEX 01 00:00:00

But with maybe FLAC instead. Depending on the users choice.

Most users want single tracks ripped to there computer, and RubyRipper does 
this very
well already. But adding this option would give users the option to burn there 
tracks
back to a CD, and know that it is the same as the original. This makes the 
ripped
tracks not only convenient for making play lists for your computer, MP3 players 
etc,
but also a very good backup of the original CD.

Original comment by colin.n....@gmail.com on 24 Nov 2007 at 9:54

[GoogleCodeExporter]

I, too, would love to see the implementation of ripping to a single file with a
cuesheet.  To have this functionality, currently I am obligated to use K3B, 
which I
don't care for much. :/  Good luck, and thanks for the excellent application, 
even
though I don't use it currently.

Original comment by wrk...@gmail.com on 4 Dec 2007 at 8:53

[GoogleCodeExporter]

Agreed, having cuesheet support for multiple files would be awesome!

Original comment by Apo...@gmail.com on 15 Feb 2008 at 9:25

[GoogleCodeExporter]

Comment12: Collin.

I guess you're using the cue sheet as intelligent playlist?

Which application supports the "multiple" files cuesheet?
I tried Amarok, Audacious asf. on standard .wav rips and none of them were 
working 
properly with a cue sheet you're listing above.

However. If a cuesheet function is introduced one should be able to 
differentiate
between a single file cue sheet and a multiple file cue sheet.

THX

Original comment by kls.schlz@gmail.com on 29 Feb 2008 at 8:56

[GoogleCodeExporter]

I too would very much like to see a cuesheet function in rubyripper (it's the 
only 
major feature I was still missing), therefore please consider the attached 
patch. 
Please comment, I haven't coded a single line of Ruby before this weekend. :)

It adds the following features:
- Single file rip
- Cuesheet generation (single / multifile) (+ embedding it into the flac, 
although 
I'm not sure how to verify this)

I modified the GTK2 version to reflect these changes, the CLI version still 
needs to 
be done.

The single file rip feature probably isn't a permanent solution: I numbered the 
full 
CD as track 0 (probably a bit ugly, but it works), so if it encounters an error 
it 
will read the whole CD again. Not to 
mention the large amount of temporary space required. It's pretty usable for 
new CDs 
though...

The Cuesheet class that was already present seemed to do the job reasonably 
well, I 
added some tweaks here and there.
Added a REM before the comment field, because K3b wasn't able to parse the 
cuefile 
and added support for VA CDs.

I don't feel proficient enough with Ruby to touch the core of the program and 
recode 
it to sector based ripping.

Kind regards,
Jasper Capel

Original comment by jwca...@gmail.com on 16 Mar 2008 at 11:18

Attachments:

• rr_cuesheet.patch

[GoogleCodeExporter]

Thanks a lot for the patch. I'll study on it as soon as I find some time. 
(Which I do not have 
that often, since I've started a study besides my fulltime job).

Original comment by rubyripp...@gmail.com on 24 Mar 2008 at 8:15

[GoogleCodeExporter]

I've committed the code to the repository (r204). Some further testing would be
appreciated, I don't know how the cuesheet generation would behave on a CD with
multiple indexes per track.

Original comment by jwca...@gmail.com on 25 Mar 2008 at 7:57

[GoogleCodeExporter]

I don't think the CUE sheet generation is quite right when ripping to separate 
files.
 The INDEX is supposed to be the offset of a specific track within the FILE being
described.  In other words, the INDEX offsets should always (unless something 
weird
is going on, or I'm misunderstanding the usage) be 00:00:00 if each track is 
ripped
to separate files.

Original comment by uber...@gmail.com on 31 Mar 2008 at 6:13

[GoogleCodeExporter]

For more detail, this page seems to be a good reference:

http://digitalx.org/cuesheetsyntax.php#indx

Original comment by uber...@gmail.com on 31 Mar 2008 at 6:14

[GoogleCodeExporter]

Sorry to spam the cuesheet issue, but it seems as though the time specified in 
the
INDEX is incorrect as well, since the third component is intended to be a frame
number, not the number of seconds.  (and the ruby time() method is used to 
convert
the time to a string.)

Original comment by uber...@gmail.com on 31 Mar 2008 at 7:36

[GoogleCodeExporter]

Holy crap, I'm so annoying.  Please disregard my previous comment--I've just 
noticed
the custom time method that converts back into frames. :-)

Original comment by uber...@gmail.com on 31 Mar 2008 at 8:14

[GoogleCodeExporter]

I am busy on this one. With a hack we made the cuefile possible. Now I'm 
actually doing a 
redesign on parts of rubyripper to do this properly. Which ultimately means 
beautifull 
code :)

Please do state any problems you have with the current implementation though. 
If I don't 
like your comment I can always delete it, he, he...

Original comment by rubyripp...@gmail.com on 31 Mar 2008 at 8:22

[GoogleCodeExporter]

Ok, the current issues I see with cue sheet generation are:

- INDEX values are wrong for multi-file rips.
- CUE sheets dealing with multiple files shouldn't be embedded into FLAC files,
otherwise the flac command bitches about INDEX values not increasing. (he he)
- All the multi-file CUE sheets I've seen format it so the sections are 
delimited by
FILE statements starting at column 0.  e.g.,

REM GENRE Ambient
REM DATE 2001
REM COMMENT "Rubyripper 0.5.0"
PERFORMER "Maenad"
TITLE "a thousand petals"
FILE "01 - consequence school.flac" FLAC
  TRACK 01 AUDIO
    TITLE "consequence school"
    PERFORMER "Maenad"
    INDEX 01 00:00:00
FILE "02 - in within.flac" FLAC
  TRACK 02 AUDIO
    TITLE "in within"
    PERFORMER "Maenad"
    INDEX 01 00:00:00
FILE "03 - the one who is created.flac" FLAC
  TRACK 03 AUDIO
    TITLE "the one who is created"
    PERFORMER "Maenad"
    INDEX 01 00:00:00
FILE "04 - pigs my fly.flac" FLAC
  TRACK 04 AUDIO
    TITLE "pigs my fly"
    PERFORMER "Maenad"
    INDEX 01 00:00:00

Original comment by uber...@gmail.com on 1 Apr 2008 at 2:54

[GoogleCodeExporter]

perhaps an intermediate feature before sector based ripping
takes each track off individually using the multi track ripping method. then 
uses the
cue file to generate a single wav file or straight to the destination format.
deleting each track as you go so you will only even have the size of the CD 
plus one
track instead of the size of 2 CDs

Original comment by yellow_o...@orcon.net.nz on 3 Apr 2008 at 12:01

[GoogleCodeExporter]

Can anyone test the cue sheet generation of Rubyripper svn (r224 or higher) 
with a disc 
that actually has a pregap? You just need to rip one track and the whole 
cuesheet will be 
generated.

P.S.: There is a known issue with metadata and strange characters.

Original comment by rubyripp...@gmail.com on 10 Apr 2008 at 4:07

[GoogleCodeExporter]

I think the current svn (r225) fixes the issues mentioned in comment 24. The 
FLAC type in 
the Cuesheet is not conform the specification by the way. MP3 and WAVE are 
allowed, all 
others are not. Other codecs do get WAVE as description now.

The resulting cue file I've attached. If anyone sees any problem in it, let me 
hear you!

On a related issue, we've yet to talk about handling pregaps. I propose the 
following:
* If a cuesheet is made, prepend the gaps to the track
* if a cuesheet isn't made, append the gaps to the previous track. Tracks with 
a hidden first 
track or a pregap before track 1 should be ripped to a track 0.

In both cases the discs can be burned and be recognized by freedb or sortalike.

Original comment by rubyripp...@gmail.com on 10 Apr 2008 at 6:21

Attachments:

• [Kiss - Alive III (mp3).cue](https://storage.googleapis.com/google-code-attachments/rubyripper/issue-123/comment-27/Kiss - Alive III %28mp3%29.cue)

[GoogleCodeExporter]

In svn r226 and r227 I've moved the rip function over to sector based ripping. 
This
means that the pregaps are now prepended to the ripped track. Previously they 
were
just lost.

Original comment by rubyripp...@gmail.com on 10 Apr 2008 at 8:10

[GoogleCodeExporter]

hi!

congrats, the results really show promise!

i would gladly test it, but where do i know it from that a certain cd has 
pregaps?
but anyway, i'll test it as soon as i get an audio cd in hand

btw, could you please merge the new language files (hungarian). although they 
are
already outdated, i'm gonna update them soon, please watch that ticket too, 
thanks

Original comment by asdfasdf...@freemail.hu on 10 Apr 2008 at 10:15

[GoogleCodeExporter]

cdparanoia -Q shows the Table of Contents (TOC)

Original comment by rubyripp...@gmail.com on 11 Apr 2008 at 2:48

• Changed state: Started

[GoogleCodeExporter]

sorry but i have only 2 cds at hand, none of them seem to have pregaps (pre: no)
anyway, i'm unable to get rr work, i'll investigate it further when i have more 
free time

Original comment by asdfasdf...@freemail.hu on 13 Apr 2008 at 10:30

[GoogleCodeExporter]

using latest svn.

When cue generation is enabled, it doesn't generate the cue, but it does 
mention it
when calling flac, causing flac to fail.

Original comment by ico2ico2@gmail.com on 7 May 2008 at 8:55

[GoogleCodeExporter]

I'll try to put some time into this. Any useful messages on the console?

Original comment by jwca...@gmail.com on 3 Jun 2008 at 12:02

[GoogleCodeExporter]

I've solved the problem. Please give it another try.

Original comment by rubyripp...@gmail.com on 16 Jun 2008 at 8:44

[GoogleCodeExporter]

Maybe you can add separate button/option "Only create cue sheet"? For example, 
i have
all my collection ripped with rubyripper, and i want to add cue sheets for all 
my albums.
What i can do with it? Rip all my cds again with "generate cue sheet" enabled or
create cue with another tool and write filenames and tags manually.

Original comment by rc.4...@gmail.com on 18 Jun 2008 at 8:26

[GoogleCodeExporter]

I have tried rip to single file with current svn snapshot and this throws me
exception 'NoMethodError'. Is this feature not implemented yet?

Original comment by rc.4...@gmail.com on 18 Jun 2008 at 8:35

[GoogleCodeExporter]

I am closing the issue. The originally requested functionality is provided for. 
To keep things 
manageable I request all of you to open separate issues for anything that still 
has to be 
fixed. Thanks for all your efforts :)

Original comment by rubyripp...@gmail.com on 18 Jun 2008 at 4:15

• Changed state: Fixed