-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm trying to use flac to make backups of my CD collection, and am running into problems with disks that contain a pregap (or lead-in) before the start of track one. cdrdao rips these disks *WITHOUT* the pregap, and puts a PREGAP entry into the cue file. For my test CD (Police, Synchronicity, catalog# 0082839373524) I get (in part): TRACK 01 AUDIO PREGAP 00:00:32 INDEX 01 00:00:00 Once I import this cue file into a flac file with metaflac, however, the pregap information is *LOST*. This means I can no longer generate a correct cddb query from the embedded cue file, nor can I create a proper CD from the resulting cue/uncompressed-flac (the audio data and CD table of contents will be 'skewed' by the pregap amount, so the resulting cd-discid will be different). I am aware of the "REM FLAC__lead-in" field in the cue file exported by metaflac, but it always seems to be 88200 (2 seconds), regardless of any PREGAP or other entries in the imported cuefile. Currently, the only way I've found to be able to store a workable (generates a CD identical to cd-discid after compress/uncompress cycle) is to rip the entire disc (including the pregap) and create a cue file with an INDEX 00 entry (which flac/metaflac will properly store/retrieve): TRACK 01 AUDIO INDEX 00 00:00:00 INDEX 01 00:00:32 The main problem is this requires hacked cuefile generation tools, as neither cdrdao/toc2cue, mkcue, or cuegen create cue files like this. Are there plans for flac/metaflac to support some sort of pregap indication in imported cue files for CD backup, or is there some other work-around I'm not aware of? Any pointers to how best to deal with "problem" CDs containing pregap would also be welcome. I'm sure I'm not the first to face these issues, but I can't seem to find much useful info online... Thanks! - -- Charles Steinkuehler cstein@newtek.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFEwS2cenk4xp+mH40RAtKWAKCi9G8A1n7qhjC9ZO0lhIdFzrHkUwCdHlKD IVitcnTudp6l5nfg7OseL3I=DmKX -----END PGP SIGNATURE-----
--- Charles Steinkuehler <cstein@newtek.com> wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I'm trying to use flac to make backups of my CD collection, and am > running into problems with disks that contain a pregap (or lead-in) > before the start of track one. > > cdrdao rips these disks *WITHOUT* the pregap, and puts a PREGAP entry > into the cue file. For my test CD (Police, Synchronicity, catalog# > 0082839373524) I get (in part): > > TRACK 01 AUDIO > PREGAP 00:00:32 > INDEX 01 00:00:00 > > Once I import this cue file into a flac file with metaflac, however, > the > pregap information is *LOST*. This means I can no longer generate a > correct cddb query from the embedded cue file, nor can I create a > proper > CD from the resulting cue/uncompressed-flac (the audio data and CD > table > of contents will be 'skewed' by the pregap amount, so the resulting > cd-discid will be different). > > I am aware of the "REM FLAC__lead-in" field in the cue file exported > by > metaflac, but it always seems to be 88200 (2 seconds), regardless of > any > PREGAP or other entries in the imported cuefile. > > Currently, the only way I've found to be able to store a workable > (generates a CD identical to cd-discid after compress/uncompress > cycle) > is to rip the entire disc (including the pregap) and create a cue > file > with an INDEX 00 entry (which flac/metaflac will properly > store/retrieve): > > TRACK 01 AUDIO > INDEX 00 00:00:00 > INDEX 01 00:00:32 > > The main problem is this requires hacked cuefile generation tools, as > neither cdrdao/toc2cue, mkcue, or cuegen create cue files like this.this is the correct solution.> Are there plans for flac/metaflac to support some sort of pregap > indication in imported cue files for CD backup, or is there some > other > work-around I'm not aware of?the basic problem is that the original toc from cdrdao does not match the audio, there is an audio section that is implied by PREGAP (that must also assumed to be silence since it didn't rip it). another solution would be to prepend silence of the PREGAP length to the PCM before encoding to FLAC. I think this could be automated with a script using dd and cat. Josh __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com