I see that this was the right place to fire off this question. Thanks for your feedback. It has given me a base to start some trials. I used to use EAC on Windows, but I tend to only use open source software as much as possible and I don't use Windows any more. I gave a brief look at abcde, but it is clear I need to look at this some more. It looks like it has the potential to do everything I would need, including encoding to 2 formats at the same time, FLAC to archive or play and ogg or mp3 for the players. 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. 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. I guess right now I need to go and try both methods. If I can help with abcde I will, but I have the programming skills of a monkey (and a monkey without a decent education at that). Just some questions: Dax, this looks good. You are getting an accurate copy of the cd with this method, track 0 and all? Is cdrdao as good as cdparanoia at ripping? Does anyone know what players (Linux OS or portable)support playing of a single album FLAC file ? cheers
On Tue, 2006-09-26 at 22:06 +0200, Dan Phillips wrote:> Just some questions: > Dax, this looks good. You are getting an accurate copy of the cd with > this method, track 0 and all?I tested half a dozen audio CDs and I was able to get back the same cddbid. I'm pretty sure the cdrdao's created toc handles that fine.> Is cdrdao as good as cdparanoia at ripping? > Does anyone know what players (Linux OS or portable)support playing of a > single album FLAC file ?In my technique cdparanoia is still used to grab the individual tracks. The use of cdrdao is just to get the toc (that can be used during the burning process to re-create the original CD). I believe that cdrdao uses a reading technique similar to cdparanoia. Dax Kelson
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) iD8DBQFFGZUSenk4xp+mH40RAijYAJ9GQ6JWqtE52CEu9DdTPVIe6vTL5wCg4UXJ trsNne00ORmapl44/vIlK3M=jav7 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dax Kelson wrote:> On Tue, 2006-09-26 at 22:06 +0200, Dan Phillips wrote: >> Just some questions: >> Dax, this looks good. You are getting an accurate copy of the cd with >> this method, track 0 and all? > > I tested half a dozen audio CDs and I was able to get back the same > cddbid. I'm pretty sure the cdrdao's created toc handles that fine.Try a disc that has track one starting on a non-zero frame (see previous post for an example). If track one starts at frame zero (as on most discs), you will be able to recover the correct cddb discid after ripping with cdrdao and converting the toc to a cue file. - -- Charles Steinkuehler cstein@newtek.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) iD8DBQFFGZXQenk4xp+mH40RAsmyAJ44vaT/gO73eW9FSepBSRE+gzSW2gCg6Ayv 32uN8SPjXJeaTyxn4CnlOW0=gtpA -----END PGP SIGNATURE-----
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.comSorry, 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?)
On 9/26/06, Dan Phillips <dwp@rushpost.com> wrote:> I see that this was the right place to fire off this question.Not really. This is the nice quiet list for folks who need help with flac.. You have confused it with the thousands of 'how do I archive my CDs?' threads that have been all over the internet for many years. Ironically, the flac data loss bug which I saw as critical, and joined the list to report, was deemed a very low priority and remained unfixed last I checked.. So maybe I'm the one on the wrong list...
Free Lunch wrote:> On 9/26/06, Dan Phillips <dwp@rushpost.com> wrote: >> I see that this was the right place to fire off this question. > > Not really. This is the nice quiet list for folks who need help with > flac.. > > You have confused it with the thousands of 'how do I archive my CDs?' > threads that have been all over the internet for many years. > > Ironically, the flac data loss bug which I saw as critical, and joined > the list to report, was deemed a very low priority and remained > unfixed last I checked.. So maybe I'm the one on the wrong list...There are plenty of ways around this, but I originally backed up all my CD's with FLAC a couple of years ago. I did an OK job, but I can not guarantee that I could get them all back to a CD. I would like to carry on with FLAC, it is (as far as I know) the only lossless compression format that is open source. It works well with the players and it is flexible. What is this data loss bug? I have not heard of this. Where do you suggest is a better place to talk about this?
--- Free Lunch <freelunch@gmail.com> wrote:> On 9/26/06, Dan Phillips <dwp@rushpost.com> wrote: > > I see that this was the right place to fire off this question. > > Not really. This is the nice quiet list for folks who need help with > flac.. > > You have confused it with the thousands of 'how do I archive my CDs?' > threads that have been all over the internet for many years. > > Ironically, the flac data loss bug which I saw as critical, and > joined > the list to report, was deemed a very low priority and remained > unfixed last I checked.. So maybe I'm the one on the wrong list...I don't remember seeing this and I don't see any other emails from you in the archive. this is a members-only list so if you send it before subscribing it would be buried in all the other spam we get and rejected. feel free to send it again. Josh __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com