I just realized that a FreeDB DiscID that was computed from the CUESHEET metadata block of a "single image" FLAC file didn't match the DiscID reported by EAC. I checked on FreeDB to confirm.
I found out that the PREGAP of track 01 (37 frames, or 21,756 samples) on one particular album needed to be added to the number of lead-in samples (88,200) in order to compute the correct DiscID.
Any thoughts?

Hmm, I seem to recall a thread recently (started by me) which discussed why a cuesheet doesn't contain enough information to generate a correct freedb lookup, which a properly created TOC file would. greynol pointed out two items that might be missing from the cue sheet:

http://www.hydrogenaudio.org/forums/index....0583&hl=toc

-brendan

The difference here is that I'm talking about an embedded cue sheet in a FLAC file, which, as far as I know, is capable of providing all the needed information. I'm only suggesting that there might be a bug in flac / metaflac, in that it should, maybe, add whatever PREGAP value it finds for track 01 to the "number of lead-in samples" stored in the metadata block.

Yes, the absolute position of the 01 index of each track is necessary along with the total length of the disc in seconds in order to calcuate a disc ID. All times must also take into account the 2 second lead-in.

That flac doesn't include this as a feature does not mean that it is a bug.

But the FAQ says:

So, whatever the solution might be, there's definitely a problem if implementing the original intent fails.

there was a thread on the flac mailing list about this. the current FLAC parser does not support the cdrdao PREGAP command. I'm not sure exactly how to handle it. it appears to use it to be a placeholder for silence that occurs between the end of the leadin (i.e. TOC i.e. first 150 sectors) and TRACK 01 INDEX 01. this is not always silent or even empty and if ripped in EAC as an image you actually get samples from it.

I think someone's workaround was to transmute the cue sheet so that the PREGAP became TRACK 01 INDEX 00, and increment the rest of the index times by the pregap length, and prepending that many samples of silence to the input. with standard unix tools this is not as hard as it sounds. when the cuesheet is corrected this way the correct cddb/cdindex IDs are generated.

Josh

Works for me, but it means that the CUESHEET metadata block can't reliably produce the exact same cue sheet as the original, which is kind of annoying when one wants to make 1:1 copies (never mind the fact that one also needs to check the cue sheet beforehand and use a custom tool to convert it if necessary).

The way I see it, the bottom line is that the specifications of the CUESHEET metadata block are incomplete. It was bad enough that it doesn't include CD-TEXT; what do people use FreeDB for in the first place? To get TITLE and PERFORMER. Where are they supposed to store that information, once they've used the computed DiscID to look it up, if they can't embed it in the FLAC file? In a local database, which is not portable. Why the metadata block includes ISRC, which is also stored in subcode data, but not CD-TEXT, is beyond me.

How come? Such information can be stored in any vorbis comment block, and, for instance, in a CUESHEET tag.


Why aren't PERFORMER/TITLE/etc tags stored in the FLAC CUESHEET block?

If you're going to store the whole cue sheet in a vorbis comment field (which was meant for holding only one-liners), why bother with a special metadata block, which application developers need to write additional code for?

Edit: don't get me wrong, I think the idea to embed a cue sheet in a FLAC file was brilliant. I'm only saying that the implementation of that idea is incomplete.


I linked to that FAQ entry myself in this thread, thank you. But I don't see what's so complex about CD-TEXT, as far as cue sheets are concerned. I don't see what CD-G and whatnot have to do with cue sheets. All I'm talking about is a handful of harmless text fields. And some people might want to tag their files another way, yes, but the point is to not only have some basic tagging available, but also to preserve compatibility with CD ripping and burning software.

Anyway, back to the original issue: is Josh considering modifying the specs at all? Or are we doomed to check and convert cue sheets ourselves?

it's not supposed to. there is no one cuesheet standard; different software write different things and the same cuesheet can be expressed in different ways, the same way you can have 2 WAVE files with the exact same audio but different 'fmt' chunks. the CUESHEET metadata (as opposed to importing the whole cuesheet as text into a tag) is meant to represent totally the logical track+index structure in a way that is easily accessible programatically and to allow disc IDs to be computed, without the app having to parse text cuesheets.

the reason I said I'm not sure how to handle PREGAP yet is because unlike EAC, cdrdao does not rip the pregap samples, it assumes they are silence and replaces those samples with a PREGAP command of the same length, which on writing is expanded back to silence. in my opinion EAC's method of ripping is better. but to make PREGAP work in flac I would have to prepend the silence samples (which is not lossless vis-a-vis the input) and it perpetuates the illusion that cdrdao is actually reading the pregap.

Josh

I guess the sanest approach to solving the issue would be to stick as closely as possible to the Red Book (or whichever colour of the rainbow is concerned). What physical property of the CD does that "PREGAP" command represent? I don't suppose you have the actual (expensive) rainbow books at your disposal?
If a "PREGAP" is technically the same as a silent INDEX 00-01 gap, then interpreting it as such might be the way to go…

Appologies for reviving the topic, but I ran across this while searching for something else.

Looking at what was posted in that other thread, so long as we are dealing image/cue, and the original cue was "properly" generated, calculating the freeDB ID shouldn't be a problem. Recently i've been trying to deal with another problem (syncronizing my image/cue files with local freedb), and I put together a small program to see if I could generate the correct freeDB ID. Granted I wouldn't call what i've done extensively tested, but for the 40-50 image/cue files i've tested against it has shown to provide correct results. (All files were created by EAC 0.95b4)

As to what the original poster has said, i'm not entirely sure how PREGAP modifies the track times compared to INDEX 00 entries, but so long as individual start times of the tracks could be properly determined, it should be possible to make slight modifications to what i've written to generate a proper ID.

-----
Domain

Yes, the PREGAP command is covering the part of the disc right after the first two seconds of track one's pause area located right after the lead-in. The PREGGAP then instructs how many additional samples the pause area of track one should consist of after the first standard 2 seconds i.e. track 1 index 00.

Hmmm, if I understand you correctly PREGAP can only exist before the first track, not any tracks thereafter? Seeing as I haven't encountered any cuesheets with PREGAP specified, does it "replace" INDEX 00 of the first track, or does it specify a time, and then INDEX 01 starts at 00:00:00?

-----
Domain

Hi Domain

The PREGAP command can be set on any track wanted and not only the first track. The PREGAP command instructs that a pause are should be made on that specific track and that it should be filled with generated silence and not audio data from an audio file. When e.g. a PREGAP command is set for the first track and with e.g. 32 samples, then that means that after the normal 2 seconds pause area of track one(which always is generated no matter what), then there should additionally be added 32 null samples to the first track's pause area, so this means that track one's pause area is now 2 seconds and 32 samples long instead of only 2 seconds(as it would have been without any PREGAP command present). This is done because those 32 samples aren't ripped from the disc in standard track ripping mode and so to make the CDs length to be exactly the same as the original CD when burned to disc, so that the e.g. correct DISCID can be calculated from the copy, then EAC inserts a PREGAP command into the cuesheet. If ripping to an image instead, then all samples are extracted from the disc, except the first 2 seconds of track one's pause area, which is never ripped or played back, so this means that EAC dosen't need to add a PREGAP command, since those 32 samples have been ripped now and is located at the beginning of the Range rip file and then so instead of setting a PREGAP command for defining track one's pause area to be 2 seconds and 32 samples long, then instead an INDEX 00 of 32 samples of track one is defined of the Range file, and then afterwards INDEX 01 is set for the rest of track one's playing time from the Range file. When having a CD with e.g. 32 samples of INDEX 00 of track one, then it means that track one's pause area is 2 seconds and 32 samples long and not only 32 samples long. The Red Book defines track one's pause area to be between 2 and 3 seconds long. PS: i say pause area instead of pre-gap, because that is the correct terminology for audio CDs, as pre-gap and post-gap are actually meant for data CDs.

Sorry for babling on here and i hope that you will understand what i'm meaning here despite of me being so bad at explaining technical things to other poeple...

CU, Martin.

Thank you for explaining this

If I understand correctly, then EAC will not generate a PREGAP so long as you are ripping the entire image. I was able to use another program that actually generated PREGAP(s) for a image/cue, though I'm not entirely sure that the results would be consistent among programs that use this method.

From what I can gather, if using PREGAP's, INDEX 01 of TRACK 01 is always 00:00:00. In terms of calculating the cddb/freedb ID, the start time of all the tracks are now off and have to be modified with this initial PREGAP, and the total disc length needs to be recalculated before a correct result will be obtained.

I've made some modifications to what i've written, and the calculation works for these cuesheet's containing PREGAP, but again I can really be sure if another program might represent the cuesheet differently. I did notice that EAC will refuse to write these cuesheets, as it states only one PREGAP is allowed, and it must exist before INDEX 01 of TRACK 01, whereas the program in question replaced all INDEX 00 entries with PREGAP.

-----
Domain

Hi again

Yes, EAC will rip the INDEX 00 of track one if present(the part after the first two seconds) in image ripping mode and i would think that all image rippers would do that(although there are drives that dosen't support reading at this possition). If a ripping app rips INDEX 00 possitions from either the first track or any track, then PREGAP is not defined in the cuesheet, as the INDEX 00 data dosen't have to be automatically generated during writing by the firmware, but instead is present in the ripped file and then instead is defined with a INDEX 00 command that takes the pause area audio data directly from the ripped audio file instead. When e.g. ripping in EAC with the non-compliant track rippping mode, then the PREGAP command is used so that the total length of the CD will match the original and hence make freedb lookups possible. Also when e.g. ripping in EAC in the track mode that leaves out gaps and then also make a cuesheet that matches that ripping mode in EAC, then there will be a PREGAP command in the cuesheet for every track, with the amount of the original INDEX 00 possition that was left out of the rip and hence, when written back to disc, will have the same INDEX 00 possitions between tracks as the original disc, but they will just be consisting of silence, no matter if the original disc had INDEX 00 possitions of real audio data.

On a CD-DA, then there first comes the lead-in which holds the TOC in it's Q subchannel and where the rest of the subchannels + mainchannel data contains nothing but null samples(unless there exists CD-TEXT, which then will be located in the R-W subchannels in lead-in or rarely in the R-W subchannels throughout the mainchannel data). Then comes the standard 2 seconds pause area of track one i.e. INDEX 00 of track one and which starts at sector -150(absolute time 00:00:00:00) to sector -1. Then from sector 0(absolute time 00:00:02:00), then either the INDEX 01 of track one starts, or the pause area of track one is longer than the standard 2 seconds and then the INDEX 00 continues additionally from sector 0 and onwards. When ripping images, then the ripping starts at sector 0 so that you will get any possible pause area after the first two seconds of track one extracted in the image also. Track ripping starts from INDEX 01 of track one, which can be at any sector from sector 0 and onwards. The PREGAP command when set for track one at e.g. 32 samples, will then extend the standard 2 seconds pause area of track one i.e. sector -150 to -1, with additionally 32 samples from sector 0 to 31 and then INDEX 01 of track one starts at sector 32. The CD player will though show 00:00:00:00 at track one's start i.e. INDEX 01, no matter what.

The PREGAP command can exist once for each track but must come after a TRACK command and before any INDEX commands.

CU, Martin.