Charles Steinkuehler wrote:> Dan Phillips wrote:
> >> With regards the toc problem not compensating for starting from
track
> >> 0, is it possible to use the cdrtoa -t or -T options to
compensate for
> >> the shift. I am not sure I fully understand the option, but I came
> >> across it and thought I would mention it.
>
> I believe the -T and -t flags (to cdparanoia? AFAIK, cdrdao doesn't
> support -T or -t switches, and I've never heard of cdrtoa) allow for
> adjusting how audio data is read from the CD (ie: in case your drive
> doesn't accurately position...similar to -O, but by altering the LBA
> address (-t) or fixing buggy drive behavior (-T) instead of adjusting
> the rip position by individual samples (-O)). These three options are
> for fixing the "rip position", making sure the audio samples in
your
> ripped file match the correct samples on the disc. None of these
> options fix the problem with the TOC/CUE file on discs that don't start
> at 'zero' (more below).
>
> >> The method I was using was this one I found through google - all
in one
> >> file like this:
> >> cdrdao read-cd --with-cddb --datafile album.bin album.toc
> >> cueconvert album.toc album.cue
> >> flac --endian=big --sign=signed --channels=2 --bps=16
> >> --sample-rate=44100 --cuesheet=album.cue album.bin
> >>
> >> Works going there, but not sure about getting back.
>
> The problem with this (in my experience) is it won't
"cleanly" make a
> flac/cue file that will match the original CD's discid (cddb query).
If
> all your discs have track 1 starting at frame zero, you're golden.
>
> By way of example, below are some results from my "problem" CD
(The
> Police, Synchronicity). First, I read the TOC using cdrdao...note that
> track one starts at frame 32, *NOT* at frame zero. When converted to a
> cue file and merged into a flac file, any pregap *DISAPPEARS*, which
> means you can no longer create a proper cddb discid! Even more, cdrdao
> *DOES NOT RIP* the first 32 frames of the disc!!! Maybe the first 32
> frames are all digital silence, but I want to make flac files that
> *EXACTLY* match the audio on my CDs (kind of the point of lossless
> compression, isn't it?!?). Using cdparanoia and specifying a start of
> track one has a similar effect (rip starts at frame 32, not at frame
> zero!), but cdparanoia allows specifying a start track of zero (only
> valid for disks with non-zero start frames for track 1!) or a specific
> LBA ([0:0:0.0] indicates sector zero, and works for all discs).
>
> Finally, note that EAC correctly rips the *ENTIRE* disc (including the
> first 32 frames!), creates a cue file that matches (example below), and
> which can be attached as metadata to a flac file. A correct cddb discid
> can then be calculated from the resulting flac/cue file combo for
> subsequent rips or other usage (recent audio players are beginning to
> support the resulting flac/cue file combo as the same as the actual CD,
> in terms of how they behave when playing, pulling up track/artist info
> based on cddb query in addition to any embedded metadata).
>
> The difference between a PREGAP entry in your cuefile (cdrdao) and an
> INDEX 00 entry (EAC) might not seem like much, but it's the difference
> between having the entire CD in your ripped file or just part of it.
>
> Ugly TOC/cuefile details follow...
>
> <quote>
> naibed:/home/music# cdrdao read-toc --device /dev/cdrom --fast-toc
> Synchronicity.toc
>
> Cdrdao version 1.1.9 - (C) Andreas Mueller <andreas@daneb.de>
> SCSI interface library - (C) Joerg Schilling
> Paranoia DAE library - (C) Monty
>
> Check http://cdrdao.sourceforge.net/drives.html#dt for current driver
> tables.
>
> Using libscg version 'schily-0.8'
>
> /dev/cdrom: PLEXTOR DVDR PX-712A Rev: 1.01
> Using driver: Generic SCSI-3/MMC - Version 2.0 (options 0x0000)
>
> Reading toc data...
>
> Track Mode Flags Start Length
> ------------------------------------------------------------
> 1 AUDIO 0 00:00:32( 32) 03:22:55( 15205)
> 2 AUDIO 0 03:23:12( 15237) 03:36:60( 16260)
> 3 AUDIO 0 06:59:72( 31497) 04:02:18( 18168)
> 4 AUDIO 0 11:02:15( 49665) 03:05:45( 13920)
> 5 AUDIO 0 14:07:60( 63585) 02:00:00( 9000)
> 6 AUDIO 0 16:07:60( 72585) 05:05:10( 22885)
> 7 AUDIO 0 21:12:70( 95470) 04:14:02( 19052)
> 8 AUDIO 0 25:26:72(114522) 04:59:03( 22428)
> 9 AUDIO 0 30:26:00(136950) 05:13:55( 23530)
> 10 AUDIO 0 35:39:55(160480) 04:15:37( 19162)
> 11 AUDIO 0 39:55:17(179642) 04:33:53( 20528)
> Leadout AUDIO 0 44:28:70(200170)
>
> <snip>
> Reading of toc data finished successfully.
> naibed:/home/music# cueconvert Synchronicity.toc Synchronicity.cue
> naibed:/home/music# cat Synchronicity.cue
> CATALOG 0082839373524
>
> FILE "data.wav" WAVE
> TRACK 01 AUDIO
> PREGAP 00:00:32
> INDEX 00 00:00:-32
> INDEX 01 00:00:00
>
> TRACK 02 AUDIO
> INDEX 01 03:22:55
>
> TRACK 03 AUDIO
> INDEX 01 06:59:40
> <snip>
> </quote>
>
> <EAC cuefile>
> REM GENRE Rock
> REM DATE 1983
> REM DISCID 9B0A6C0B
> REM COMMENT "ExactAudioCopy v0.95b4"
> PERFORMER "Police"
> TITLE "Synchronicity"
> FILE "Police - Synchronicity.wav" WAVE
> TRACK 01 AUDIO
> TITLE "Synchronicity I"
> PERFORMER "Police"
> INDEX 00 00:00:00
> INDEX 01 00:00:32
> TRACK 02 AUDIO
> TITLE "Walking in your footsteps"
> PERFORMER "Police"
> INDEX 01 03:23:12
> <snip>
> </EAC cuefile>
>
> --
> Charles Steinkuehler
> cstein@newtek.com
Sorry, that was a typo cdrtoa should have been cdrdao.
Thanks for that, yes I can see the problem and why those flags not help.
What we are left with is a requirement in abcde to overcome this and
until then we have the manual method. Have you any thoughts on the best
way to overcome this problem apart from the hacked toc3cue (do you have
a copy of this?)