Menu
▾
▴
|
From: Grant <ema...@gm...> - 2010-07-15 02:12:55
Attachments:
cdrdao.txt
|
I love cdrdao and I've been using it to rip CDs for a long time. Recently I ran across 2 CDs that it has a problem ripping. Both are The Beatles remastered Enhanced CDs "Please Please Me" and "With The Beatles". cdrdao seems to have a problem detecting the end point of the last audio track. I've attached the output of the read-cd command. After splitting according to cdrdao's toc, the 14th track includes about a minute of silence on the end followed by another minute of a buzzing noise. Another annoyance is the fact that the non-audio data portion of the Enhanced CD ends up being split and encoded to flac as track 15 based on cdrdao's toc. - Grant |
|
From: Grant <ema...@gm...> - 2010-07-16 00:47:10
|
> I love cdrdao and I've been using it to rip CDs for a long time. > Recently I ran across 2 CDs that it has a problem ripping. Both are > The Beatles remastered Enhanced CDs "Please Please Me" and "With The > Beatles". cdrdao seems to have a problem detecting the end point of > the last audio track. I've attached the output of the read-cd > command. After splitting according to cdrdao's toc, the 14th track > includes about a minute of silence on the end followed by another > minute of a buzzing noise. Another annoyance is the fact that the > non-audio data portion of the Enhanced CD ends up being split and > encoded to flac as track 15 based on cdrdao's toc. > > - Grant I should mention that rubyripper creates the cuesheet correctly. I'd really like to stick with cdrdao though. - Grant |
|
From: Grant <ema...@gm...> - 2010-07-16 01:13:10
|
>> I love cdrdao and I've been using it to rip CDs for a long time. >> Recently I ran across 2 CDs that it has a problem ripping. Both are >> The Beatles remastered Enhanced CDs "Please Please Me" and "With The >> Beatles". cdrdao seems to have a problem detecting the end point of >> the last audio track. I've attached the output of the read-cd >> command. After splitting according to cdrdao's toc, the 14th track >> includes about a minute of silence on the end followed by another >> minute of a buzzing noise. Another annoyance is the fact that the >> non-audio data portion of the Enhanced CD ends up being split and >> encoded to flac as track 15 based on cdrdao's toc. >> >> - Grant > > I should mention that rubyripper creates the cuesheet correctly. I'd > really like to stick with cdrdao though. > > - Grant This problem is actually documented here: http://en.wikipedia.org/wiki/Enhanced_CD "Sometimes computer CD-ripping programs (particularly cdparanoia) have problems ripping some enhanced CDs, especially those that have the data in a separate session after the audio section. These CDs have the data 11,400 sectors (2m32s) after the audio, but some CD rippers may try to rip this blank section with the last track; the end result is that the ripper stalls during the last track, or simply reports errors." - Grant |
|
From: Grant <ema...@gm...> - 2010-07-16 05:38:41
|
>>> I love cdrdao and I've been using it to rip CDs for a long time. >>> Recently I ran across 2 CDs that it has a problem ripping. Both are >>> The Beatles remastered Enhanced CDs "Please Please Me" and "With The >>> Beatles". cdrdao seems to have a problem detecting the end point of >>> the last audio track. I've attached the output of the read-cd >>> command. After splitting according to cdrdao's toc, the 14th track >>> includes about a minute of silence on the end followed by another >>> minute of a buzzing noise. Another annoyance is the fact that the >>> non-audio data portion of the Enhanced CD ends up being split and >>> encoded to flac as track 15 based on cdrdao's toc. >>> >>> - Grant >> >> I should mention that rubyripper creates the cuesheet correctly. I'd >> really like to stick with cdrdao though. >> >> - Grant > > This problem is actually documented here: > > http://en.wikipedia.org/wiki/Enhanced_CD > > "Sometimes computer CD-ripping programs (particularly cdparanoia) have > problems ripping some enhanced CDs, especially those that have the > data in a separate session after the audio section. These CDs have the > data 11,400 sectors (2m32s) after the audio, but some CD rippers may > try to rip this blank section with the last track; the end result is > that the ripper stalls during the last track, or simply reports > errors." > > - Grant I should also mention that it works correctly in rubyripper, and actually works in cdrdao maybe 10% of the time so it's inconsistent in cdrdao. - Grant |