Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: FLAC + cuesheets (Read 11764 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

FLAC + cuesheets

I have done some work adding a new CUESHEET metadata block type to FLAC.  It is mostly finished but before I set it in stone I want to get feedback from people about it.  Please stay with my short explanation here and I'll get to the help request at the end.

The block is for storing various info that you would normally find in a CD-DA cue sheet.  It supports track and index points and other CD-DA metadata such as media catalog number and track ISRCs.  It's main purpose is for use in backing up CD-DA discs as a single FLAC file, but I tried to generalize it so that it can be used as a general purpose cueing mechanism for playback also.

Right now (with what's in CVS) you can, say, rip with EAC to one big WAV+CUE, then use --cuesheet=filename with flac while encoding and it will parse the cuesheet and create a CUESHEET block automatically.  It will also add seekpoints for all of the index points.  Then, you can metaflac --export-cuesheet-to=filename to dump the CUESHEET block to text form suitable for burning software.

Eventually I would like to add support in the plugins so that when you load such a FLAC file it will appear as multiple tracks, and also some way of being able to add individual tracks into playlists.

Now, with all that in mind, I have documented the block here for your perusal.  I have read up as much as I could on CD-DA and done a lot of experimenting on CDs but it's likely that I have missed something.  I would really appreciate it if you all took a look (especially Pio2001  ) and let me know of any assumptions that are wrong or anything that could be done better.  You will see a few places marked with @@@@ where I am not sure about something.

After I collect all this wisdom I will incorporate it and roll a 1.0.5-alpha source release so people can play with it (if you're really anxious you can check out from CVS and try it now).  It should be much easier to build on Windows now since I have gone and made .dsp files for everything, for every combination of static lib and DLL, and debug and release builds.

So please let me know what you think!

Josh

FLAC + cuesheets

Reply #1
Josh,
I think this is a great idea, one which I have been thinking about myself for some time!
I actually created my own dodgy format for archiving CD's using a single flac file and an XML file encapsulating the same info as the TOC(cuesheet) file, I then wrote a simple player to play my files as though they were CD's. I think yours is a better idea tho, and I will certainly be looking into it over the coming weeks(holidays coming up!).

My only concern is that of convienience, should I store as song-per-file or album-per-file? My interest is not only in perfectly archiving my CD's but also having them in a convienient format to play them on the computer through a number of different programs. If this album-per-file format catches on, and the xmms/winamp plugins supported playing individual tracks, then we will have the best of both worlds. I dont know enough about the plugins to know whether this is possible/makes sense or not, I hope it can be done.

Back when I got my first CD-Burner in 97, I read up on the CDDA format, and wrote lots of my own cdrwin CUE sheets to do funky stuff like having songs in the extended pre-gap of the first tract, ie. tracks you can only get to by pressing 'play' then holding down 'rewind' to go back past the beginning, pretty cool! There are a few commercial cd's with these 'hidden tracks', Better Than Ezra's 'Friction Baby' springs to mind. Any good CD backup system MUST support such things (this one will, in theory anyway, plugins may present 'issues' tho). Unfortunately I have forgotten most of what I know about CDDA, but at first glance things look good!

Anyway, this is great news, and very timely too (I started working on my old program again just yesterday, I will now move to this new format).
You can be sure I'll be looking into it, and help out in any way I can.

Dave

PS, how do you plan to deal with other types of audio cds eg. cd-extras with data tracks?

FLAC + cuesheets

Reply #2
Off-topic: Is there a software that can burn directly from flac to cd-r yet?

FLAC + cuesheets

Reply #3
Quote
songs in the extended pre-gap of the first tract, ie. tracks you can only get to by pressing 'play' then holding down 'rewind' to go back past the beginning, pretty cool! There are a few commercial cd's with these 'hidden tracks', Better Than Ezra's 'Friction Baby' springs to mind.

OT:

wait a sec., my Friction, Baby doesn't have that! (just checked) are you sure about this?
A riddle is a short sword attached to the next 2000 years.

FLAC + cuesheets

Reply #4
Quote
Josh,
Back when I got my first CD-Burner in 97, I read up on the CDDA format, and wrote lots of my own cdrwin CUE sheets to do funky stuff like having songs in the extended pre-gap of the first tract, ie. tracks you can only get to by pressing 'play' then holding down 'rewind' to go back past the beginning, pretty cool! There are a few commercial cd's with these 'hidden tracks', Better Than Ezra's 'Friction Baby' springs to mind. Any good CD backup system MUST support such things (this one will, in theory anyway, plugins may present 'issues' tho). Unfortunately I have forgotten most of what I know about CDDA, but at first glance things look good!


Yes, this will be possible; as long as the ripper grabs it properly and detects the TRACK 01 INDEX 00 everything will work as expected.

Quote
PS, how do you plan to deal with other types of audio cds eg. cd-extras with data tracks?


It will store the track offsets in the CUESHEET and they will have a type of non-audio, but there's no plan to store the track data in the FLAC file.  I'm not sure how it can be done but I'm guessing there is a way to rip them to data files, then when burning you could edit the metaflac-exported cuesheet to refer to them.

One more thing I forgot to ask, does anyone know of a script or proggie to take the informational output of cdda2wav and create a cuesheet?  cdda2wav from cdrtools can read the media catalog number, track isrcs, and index points pretty well.  If not I'll just make one.

Josh

 

FLAC + cuesheets

Reply #5
I am no expert in this area but i have had a look at the spec you have written up and it seems ok to me.

One thing i did notice was that CD-DA allows for the provision of CD-TEXT as far as i am aware, i could see no mention of it in the spec, perhaps i am completly blind or don't understand the complexity of it all though. 

If there is no provision for the text and it was going to be taken from comment tags, is there a maximum lenght to this text and what format does it use?


Other than that, a great idea, especially the plugin support to show multiple tracks. especially if RG is impimented as well.

Cheers,

Kristian

FLAC + cuesheets

Reply #6
Hi everyone,

I'm currently finishing the specs of MCF (Multimedia Container Format) and we've been thinking about saving this kind of meta informations already.
The system is not based on any existing system but based on what would be usefull and easy to handle. You can check it here in the Chapter section. The Chapter section allows overlapping and inclusion of timecode. But nothing similar to a index in a track.

In MCF you can store audio and video, and the idea was to be able to put a whole CD in one file with all possible meta info needed. The only thing I think is not possible is to have a file that start playing at (timecode) 0 and then you'd be able to have data backward. It may still be possible if the 1st Chapter doesn't cover the beggining of the data and the player only read data based on the Chapter informations of the film.

Why do I post it here ? Because we may borrow share some ideas to improve both formats  (for example CD-Text informations and ISRC is already handled but for a whole track).

FLAC + cuesheets

Reply #7
BTW, in MCF we handle ISRC at the subtrack level (for different languages for example). There can also be different audio tracks in a file like the main one and the author commenting the picture (in case of a movie). That's the basic difference between the track and the subtrack.

Given the definition of ISRC (http://www.riaa.org/Audio-Standards-3.cfm) I think that's the way to handle it, because it corresponds to the version of the recording, so different languages (that can use the same main channels and additional mix over, it requires a codec that can do that) are different recordings. So basically a mix CD with overlapping tracks, should also have overlapping ISRC codes (or a complete one for the whole recording, or both). I think I may add this support in MCF...

FLAC + cuesheets

Reply #8
Quote
One thing i did notice was that CD-DA allows for the provision of CD-TEXT as far as i am aware, i could see no mention of it in the spec, perhaps i am completly blind or don't understand the complexity of it all though.  ;)

On the surface CD-TEXT seems pretty simple but when I dug in to the full standard it was quite complex.  It is internationalized, but not through unicode, it has several different character sets, some of them multibyte.  It also allows for not just text but images as well.

Quote
If there is no provision for the text and it was going to be taken from comment tags, is there a maximum lenght to this text and what format does it use?

The idea is this: since the TOC can be calculated from the CUESHEET, different hashes like CDDB and CDindex can be computed too.  Then you can pull metadata straight from local or networked databases from the player.

At one time I though of having multiple VORBIS_COMMENT blocks in the FLAC file, one for each track, but that is just not wieldy.

Quote
Other than that, a great idea, especially the plugin support to show multiple tracks. especially if RG is impimented as well.

One implication of having one FLAC per CD is that the album and track gains will be the same since there is only one VORBIS_COMMENT block and I did not want to extend the current ReplayGain convention regarding tags.

Josh

FLAC + cuesheets

Reply #9
Quote
BTW, in MCF we handle ISRC at the subtrack level (for different languages for example). There can also be different audio tracks in a file like the main one and the author commenting the picture (in case of a movie). That's the basic difference between the track and the subtrack.

Given the definition of ISRC (http://www.riaa.org/Audio-Standards-3.cfm) I think that's the way to handle it, because it corresponds to the version of the recording, so different languages (that can use the same main channels and additional mix over, it requires a codec that can do that) are different recordings. So basically a mix CD with overlapping tracks, should also have overlapping ISRC codes (or a complete one for the whole recording, or both). I think I may add this support in MCF...


You're right.  The ISRC support in a FLAC CUESHEET is really only for CD-DA; if an app requires better ISRC tracking I would expect it to use multiple FLAC streams and mux them together in a real container like MCF.  The native FLAC transport is not meant for anything but audio data, so the more complex the metadata gets, the more kludgy in becomes to put into FLAC metadata blocks.  I tried to strike a reasonable balance with CUESHEET and for that reason other things like CD-TEXT are not in there.

Josh

FLAC + cuesheets

Reply #10
Quote
1.
On the surface CD-TEXT seems pretty simple but when I dug in to the full standard it was quite complex.  It is internationalized, but not through unicode, it has several different character sets, some of them multibyte.  It also allows for not just text but images as well.

----------
2.
The idea is this: since the TOC can be calculated from the CUESHEET, different hashes like CDDB and CDindex can be computed too.  Then you can pull metadata straight from local or networked databases from the player.

-----------

3.
At one time I though of having multiple VORBIS_COMMENT blocks in the FLAC file, one for each track, but that is just not wieldy.

-------------
4.
One implication of having one FLAC per CD is that the album and track gains will be the same since there is only one VORBIS_COMMENT block and I did not want to extend the current ReplayGain convention regarding tags.

1.
Well, i would never have guessed CD-TEXT would have been such a complex spec, and the ability to add images using the CD-TEXT standard seems very interesting but also confusing, do you have any avaliable links to the spec?

2.
I see, for burnig CD's directly from the FLAC files, that is an adequate idea, although it can be annoying when there are several versions, or if u like to modify stuff held in major databases like FreeDB.


3.
Yes, i can see a terrible mess ensueing with housing all of the tracks information in one flac, multiple blocks would make it quite hard to manage.

4.
The fact that the file will only have a single RG tag will offput a few people i know. The advancment in MPC burning directly from .mpc files with no gain, radio or album gain, directly from a cue sheet, is a feature i'd always wanted.




I can see the limitation and problems (although they are only my preferences) in my aforementioned comments, one idea that could be implimented onto yor current idea is the ability to copy an album to sepereate tracks which can house their own vorbis comments, RG radio and album data etc but also have the cue sheet block referencing each individual flac file in the album? this may be a pain but its just a thought and will allow:
  • tags
  • RG info for each track


My appologies if i have carried on or gone to far off topic,

Kristian


OT. how do you create several quotes in one post? i could only get the one quote to apper!!!

FLAC + cuesheets

Reply #11
Quote
1.
Well, i would never have guessed CD-TEXT would have been such a complex spec, and the ability to add images using the CD-TEXT standard seems very interesting but also confusing, do you have any avaliable links to the spec?

Not to the whole spec, but these should give you an idea of what it covers:
http://www.cdpage.com/Compact_Disc_Variati...ons/cdtext.html
http://www.discusa.com/cdref/cdaudio/cdtext.htm

Quote
4.
The fact that the file will only have a single RG tag will offput a few people i know. The advancment in MPC burning directly from .mpc files with no gain, radio or album gain, directly from a cue sheet, is a feature i'd always wanted.

I can see the limitation and problems (although they are only my preferences) in my aforementioned comments, one idea that could be implimented onto yor current idea is the ability to copy an album to sepereate tracks which can house their own vorbis comments, RG radio and album data etc but also have the cue sheet block referencing each individual flac file in the album? this may be a pain but its just a thought and will allow:
  • tags

  • RG info for each track


In that case you don't really need the cuesheet in the FLAC file, you can keep it to the side.  If you keep it in the FLAC file, which one do you keep it in?  The first track?  All tracks?  It becomes inelegant quickly.

The only thing you will lose is the individual track gains; the album gain will be the same.  I would argue that you only need the track gains when playing a playlist composed of multiple tracks from multiple CDs, and only when the track gains differ largely from the album gain for at least some of the CDs.

Quote
OT. how do you create several quotes in one post? i could only get the one quote to apper!!!

The forum code has changed from the old way.  Now, after clicking the quote link, in the first message box I enter a dummy line and do 'Preview Post'; that will copy the quoted item into message box, and you can edit it there.

Josh

FLAC + cuesheets

Reply #12
I was thinking about the (really) hidden tracks at the beggining of CDs and the use on computers.

Actually I don't know any software/computer player that can go backward past the beggining of a "file". So I guess this hidden data should be seen as a normal track (normally playable) which everyone will be happy with. The storing of this information is only necessary if you want to reproduce a similar CD. Am I wrong is saying that it's handled with regular CD Track and Index ? Or is there more ? (like data Track 0, index 0) 

FLAC + cuesheets

Reply #13
To answer a previous comment (ssamadhi97):
I just grabbed my BTE cd (Friction, Baby) to check I wasn't imagining things, and my version (Australian) does indeed have a hidden track at the beginning, about 3:30 in fact, its a live track in french! maby other pressings don't have it...?

In response to the last post(robUx4) and to clarify for those who are interested:
CD tracks have indicies, at the very least every track must have an 'index 01' which is stored in the TOC at the start of the CD, this is where the track officially starts. When you 'skip' to a particular track with your cd player, say, track 4, it will start playing at the location specified by track 04, index 01 in the TOC.

Tracks are also allowed to have an 'index 00' and indeed further indexes (eg, index 02, index 03 etc). The gap between index 00 and index 01 is called the 'pre-gap' of the track. What this means is that the CD player, when playing a cd sequentially, will change track numbers when it hits index 00 of a track, but the time display will count backwards till index 01 is reached then count forwards as normal. This is why you sometimes see the counter on your CD player say ""-1:00" between tracks.

Any track on a CD may have an audible 'pre-gap' of an arbitrary length, and it will only be heard when you play the CD sequentially and not when you play individual tracks. In the case of track 01, the pre-gap is never normally played, since the CD player jumps straight to track 01 index 01, you can only get there by pressing play, then rewind! Theres no fancy data track stuff going on, its all straight 'redbook' (?) CDDA. Now that you know this, you can impress your friends with the next mix-cd you make!

On the topic of pc cd-player software, I just played the CD in linux using the gnome-cd-player, and no, it didn't let me rewind past the beginning  I seem to recall being able to do it in windows all those years ago when I used that OS, but I could be wrong.

I would like to see the xmms/winamp flac plugins emulate a physical CD player *exactly* when faced with these files(ie. start playing at track 01 index 01 but allow rewind to track 01 index 00), thats my vision of this new development, the files should encapsulate a CD exactly, and the player should play them exactly as a (common) CD player would.

Dave

FLAC + cuesheets

Reply #14
Quote
I would like to see the xmms/winamp flac plugins emulate a physical CD player *exactly* when faced with these files(ie. start playing at track 01 index 01 but allow rewind to track 01 index 00), thats my vision of this new development, the files should encapsulate a CD exactly, and the player should play them exactly as a (common) CD player would.

That's the plan, or as close as is possible in any given player.  I just realized this will require a flag in the CUESHEET that says whether it corresponds to a CD-DA disc or not.

Josh

FLAC + cuesheets

Reply #15
Quote
The number of lead-in samples. This field has meaning only for CD-DA cuesheets; for other uses it should be 0. For CD-DA, the lead-in is the TRACK 00 area where the table of contents is stored; more precisely, it is the number of samples from the first sample of the media to the first sample of the first index point of the first track. According to the Red Book, the lead-in must be silence and CD grabbing software does not usually store it; additionally, the lead-in must be at least two seconds but may be longer (? @@@@). For these reasons the lead-in length is stored here so that the absolute position of the first track can be computed. Note that the lead-in stored here is the number of samples up to the first index point of the first track, not necessarily to INDEX 01 of the first track; even the first track may have INDEX 00 data.


Lead-in = Track 0
Pregap = Track 1 index 0 = absolute time 00:00:00:00
Hidden track = Further in track 1 index 0 = absolute time 00:00:02:00 = block adress 0

The CDs with hidden tracks I have don't respect this, the audio starts at time 00:00:00:00 while it should start at 00:00:02:00.
As a result, it's not possible for EAC to read them "by range", because the range starts from block 0. It's not possible either to catch the beginning of the hidden track going back in a CD player, it stops at 00:00:02:00 and doesn't go before.

However EAC can still read them hacking the registry, in order to enable ofset correction as big as -88200.

I don't fully understand the specifications given in ECMA 130, but you can get it from http://www.ecma.ch

FLAC + cuesheets

Reply #16
Quote
Quote
The number of lead-in samples. This field has meaning only for CD-DA cuesheets; for other uses it should be 0. For CD-DA, the lead-in is the TRACK 00 area where the table of contents is stored; more precisely, it is the number of samples from the first sample of the media to the first sample of the first index point of the first track. According to the Red Book, the lead-in must be silence and CD grabbing software does not usually store it; additionally, the lead-in must be at least two seconds but may be longer (? @@@@). For these reasons the lead-in length is stored here so that the absolute position of the first track can be computed. Note that the lead-in stored here is the number of samples up to the first index point of the first track, not necessarily to INDEX 01 of the first track; even the first track may have INDEX 00 data.


Lead-in = Track 0
Pregap = Track 1 index 0 = absolute time 00:00:00:00
Hidden track = Further in track 1 index 0 = absolute time 00:00:02:00 = block adress 0

The CDs with hidden tracks I have don't respect this, the audio starts at time 00:00:00:00 while it should start at 00:00:02:00.
As a result, it's not possible for EAC to read them "by range", because the range starts from block 0. It's not possible either to catch the beginning of the hidden track going back in a CD player, it stops at 00:00:02:00 and doesn't go before.

However EAC can still read them hacking the registry, in order to enable ofset correction as big as -88200.

What determines that, in your example, 00:00:02:00 is block 0?  Or is it part of the Redbook spec?

Also, is it true that the TOC (TRACK 00) may be longer than 2 sec?

Josh

FLAC + cuesheets

Reply #17
Is there any thought on the eventual possibities of individual song transfer methods of these albums, keeping the songs within a format to recombine if needed?  I know you are thinking about ripping one's own cds, but it would be nice to allow for lossless splitting and combining of each album song to song, keeping all tagging information for that song intact (that would work with the cue file I assume).
WARNING:  Changing of advanced parameters might degrade sound quality.  Modify them only if you are expirienced in audio compression!

FLAC + cuesheets

Reply #18
Quote
In response to the last post(robUx4) and to clarify for those who are interested:
CD tracks have indicies, at the very least every track must have an 'index 01' which is stored in the TOC at the start of the CD, this is where the track officially starts. When you 'skip' to a particular track with your cd player, say, track 4, it will start playing at the location specified by track 04, index 01 in the TOC.

Tracks are also allowed to have an 'index 00' and indeed further indexes (eg, index 02, index 03 etc). The gap between index 00 and index 01 is called the 'pre-gap' of the track. What this means is that the CD player, when playing a cd sequentially, will change track numbers when it hits index 00 of a track, but the time display will count backwards till index 01 is reached then count forwards as normal. This is why you sometimes see the counter on your CD player say ""-1:00" between tracks.

Any track on a CD may have an audible 'pre-gap' of an arbitrary length, and it will only be heard when you play the CD sequentially and not when you play individual tracks. In the case of track 01, the pre-gap is never normally played, since the CD player jumps straight to track 01 index 01, you can only get there by pressing play, then rewind! Theres no fancy data track stuff going on, its all straight 'redbook' (?) CDDA. Now that you know this, you can impress your friends with the next mix-cd you make!

He he. I did such mixes 3 years ago
Sounic Foundry CD Architect is really great for that

FLAC + cuesheets

Reply #19
Quote
Lead-in = Track 0
Pregap = Track 1 index 0 = absolute time 00:00:00:00
Hidden track = Further in track 1 index 0 = absolute time 00:00:02:00 = block adress 0

The CDs with hidden tracks I have don't respect this, the audio starts at time 00:00:00:00 while it should start at 00:00:02:00.
As a result, it's not possible for EAC to read them "by range", because the range starts from block 0. It's not possible either to catch the beginning of the hidden track going back in a CD player, it stops at 00:00:02:00 and doesn't go before.

However EAC can still read them hacking the registry, in order to enable ofset correction as big as -88200.

I don't fully understand the specifications given in ECMA 130, but you can get it from http://www.ecma.ch

Well, I just realised that a CD (a friend of mine released) contains a hidden track !
And it lasts about 3 minutes.
So I don't think it's just the pre-gap of Track that lasts 2s.

It is probably what davec mentions : arbitrary length of the Track1 index 0.

Now I'd be very interrested to be able to rip that particular track (because I want to use it in a mix) ! Can any software do that ?
And is it also possible to burn a CD with such a hidden track ? (maybe writing your own cuesheet)

FLAC + cuesheets

Reply #20
Quote
Is there any thought on the eventual possibities of individual song transfer methods of these albums, keeping the songs within a format to recombine if needed?  I know you are thinking about ripping one's own cds, but it would be nice to allow for lossless splitting and combining of each album song to song, keeping all tagging information for that song intact (that would work with the cue file I assume).

That's what I'd like to achieve in MCF.
But the "negative timecode" is really a problem here. Or the data won't be hidden at all (good and bad).

FLAC + cuesheets

Reply #21
BTW, how does CD rippers (I use CDEx)  handle the pregap data ? I never noticed some missing data in CDs where everything is mixed. Is it copied in the previous track (a problem for track 1) or the next track ?

FLAC + cuesheets

Reply #22
robUx4
I haven't done any cd copying for a few years (I can afford to buy them now!). But when I did, I was quite pedantic about making exact copies. ie. preserving all index points etc, especially the first pre-gap. At the time, there wasnt a lot of ripping software around, I used a cd-recording program called "cdrwin" which even now is probably the best cd-writing software for windows if you want to create custom audio cds. AFAIK it was actually cdrwin that invented the whole "cue-sheet" format to burn cds, now many other programs support the same format(even flac now!). cdrwin would rip cds and search for index points and create the cue-sheet for you, it worked very well and  preserved audible pre-gaps etc. You have to have a supported drive tho (otherwise it would automatically make all pre-gaps 2s long), mine at the time was a panasonic 4X SCSI drive, which I no longer have. I dont think that my current drive works as well, with cdparanoia if I try and rip from the start of a cd containing an audible pre-gap, I get the pre-gap, but its all silence !!! wtf? I dont know if its the drive or cdparanoia thats the culpret, I am looking into it.

As for how rippers handle pre-gaps when your ripping individual tracks, I dont know. My guess is that it would always start ripping at index 01 of the track you want (maning you loose its pre-gap), where it stops tho, is anyones guess, either index 00 of the next track, or index 01 of the next track, it probably depends on the individual ripper. If your making mixes tho, its probably not important, pre-gaps only really make sense when listening to tracks in sequence anyway.

Josh
I am starting to think CD-TEXT support is a good idea. As a means of tagging more than anything else. I dont really care about CD-TEXT as such(how many cds/players use it?) but I think it is important that you are able to 'tag' each song, so that when you play a flac-album in xmms or whatever, it will display song details etc. I know CDDB is an option but I would MUCH prefer to contain such metadata IN the file rather than on the internet, besides some people might actually care about preserving CD-TEXT itself. Can you think of any other way of storing this data in the flac file?, it doesnt have to resemble the CD-TEXT spec itself, rather just contain the same type of data... perhaps another, optional metadata header, which is a pointer to the flac/id3/ogg info headers for each track??

Dave

FLAC + cuesheets

Reply #23
Josh,
I just read those links that you provided for CD-TEXT, it certainly does look complicated!
However, what your doing with flac is to store 'cue-sheets', not preserve every "bit" on the CD, its up to the cd-recording software to take the cue-sheet and re-create the original cd (if possible). I would make a bet that the current format of cue-cheets as supported by burning software doesnt support the full features of cd-text at all, but rather a small subset, probably the equivalent of about an id3 tags' worth of info per song. Maby we could find out the cue-sheet specs and support what it supports rather try and support the full CD-TEXT format. Even if we did support the whole CDTEXT format, no burning software (that I know of) is going to anyway!

Just a thought, I'll look into it some more.
Dave

FLAC + cuesheets

Reply #24
For what it's worth, Exact Audio Copy will easily extract such "hidden" pre-gap songs... if you use the "Copy Range" feature. When you've got the "Range" panel showing all the indices, leave the top slider at "0" and drag the bottom slider to the first visible index, which (if a hidden track is present) is actually the beginning of track 1. Click "Snap to track" to make sure it is aligned, begin copying, and presto! Your hidden song is exposed.

  When I first learned how to create such hidden tracks, I added them to everything I burned. Fun, aren't they?  Another good example of this sort of hidden treasure can be found on the John Oswald's Plunderphonics/Grateful Dead double album, Grayfolded.

    - M.