Menu
▾
▴
cdrdao-devel
|
From: Thomas V. S. <th...@ap...> - 2009-06-06 17:08:46
|
Hi, I noticed that cdrdao's toc extraction always lists the length of the pregap as one frame shorter than EAC. For example, on Muse's Black Holes and revelations: - cdrdao lists, for track 11: // Track 11 TRACK AUDIO NO COPY NO PRE_EMPHASIS TWO_CHANNEL_AUDIO ISRC "GBAHT0500600" FILE "data.wav" 39:23:53 06:07:22 START 00:00:37 - EAC has: 0:00:00.38 in the ui Is it possible cdrdao has an off-by-one error here ? How can I verify whether it's cdrdao or EAC getting it wrong ? Thomas -- I looked up at Anna She turned back to look at me It's best to kill the ones that matter Render blind the ones that see -- GStreamer - bringing multimedia to your desktop http://gstreamer.freedesktop.org/ |
|
From: Thomas V. S. <th...@ap...> - 2009-07-02 21:19:10
|
On Sat, 2009-06-06 at 19:08 +0200, Thomas Vander Stichele wrote: > Hi, > > I noticed that cdrdao's toc extraction always lists the length of the > pregap as one frame shorter than EAC. For example, on Muse's Black > Holes and revelations: > > - cdrdao lists, for track 11: > // Track 11 > TRACK AUDIO > NO COPY > NO PRE_EMPHASIS > TWO_CHANNEL_AUDIO > ISRC "GBAHT0500600" > FILE "data.wav" 39:23:53 06:07:22 > START 00:00:37 > > - EAC has: 0:00:00.38 in the ui > > Is it possible cdrdao has an off-by-one error here ? How can I verify > whether it's cdrdao or EAC getting it wrong ? Anyone an idea ? I've verified this on two different drives, so I'm pretty sure I'm not seeing things. Could someone try and confirm or deny ? Thanks Thomas -- In a city that kills by constriction throw your streets around me and squeeze -- savon - Saving your work to svn https://apestaart.org/thomas/trac/ |
|
From: Thomas V. S. <th...@ap...> - 2009-07-03 08:03:52
|
As a further data point, I did the following: - read-cd cure.toc - write cure.toc - read-toc cure2.toc ie, reading a cd, writing it again, then reading the written CD. As you can clearly see from the attachments, there is an off-by-one error on the frame calculation somewhere. I'm going to assume it's in the reading part after comparing with EAC. In the bug tracker, I found https://sourceforge.net/tracker/?func=detail&aid=604751&group_id=2171&atid=102171 which looks like my bug. I'll attach my findings there. It would be nice to get this fixed, but meanwhile I'll work around it. I hope I get told though when this gets fixed :) Otherwise my workaround will get it wrong when it does. Thomas On Thu, 2009-07-02 at 23:19 +0200, Thomas Vander Stichele wrote: > On Sat, 2009-06-06 at 19:08 +0200, Thomas Vander Stichele wrote: > > Hi, > > > > I noticed that cdrdao's toc extraction always lists the length of the > > pregap as one frame shorter than EAC. For example, on Muse's Black > > Holes and revelations: > > > > - cdrdao lists, for track 11: > > // Track 11 > > TRACK AUDIO > > NO COPY > > NO PRE_EMPHASIS > > TWO_CHANNEL_AUDIO > > ISRC "GBAHT0500600" > > FILE "data.wav" 39:23:53 06:07:22 > > START 00:00:37 > > > > - EAC has: 0:00:00.38 in the ui > > > > Is it possible cdrdao has an off-by-one error here ? How can I verify > > whether it's cdrdao or EAC getting it wrong ? > > Anyone an idea ? I've verified this on two different drives, so I'm > pretty sure I'm not seeing things. > > Could someone try and confirm or deny ? > > Thanks > Thomas > -- The only thing I understood where the comma's. -- Flumotion - the only way to stream! http://www.flumotion.net/ |
|
From: Denis L. <de...@po...> - 2009-07-03 09:06:10
|
On 07/03/2009 10:03 AM, Thomas Vander Stichele wrote: > As a further data point, I did the following: > > - read-cd cure.toc > - write cure.toc > - read-toc cure2.toc > > ie, reading a cd, writing it again, then reading the written CD. > > As you can clearly see from the attachments, there is an off-by-one > error on the frame calculation somewhere. I'm going to assume it's in > the reading part after comparing with EAC. > > In the bug tracker, I found > https://sourceforge.net/tracker/?func=detail&aid=604751&group_id=2171&atid=102171 > > which looks like my bug. > > I'll attach my findings there. > > It would be nice to get this fixed, but meanwhile I'll work around it. > I hope I get told though when this gets fixed :) Otherwise my workaround > will get it wrong when it does. Thomas, I'll try to address this bug within next week, but it's tricky as this is really in the parsing core of cdrdao, which unfortunately I am not super familiar with. What is 'EAC' ? Also, have you tried the patch that is in bug 604751 first comment ? -denis |
|
From: Thomas V. S. <th...@ap...> - 2009-07-03 09:35:05
|
On Fri, 2009-07-03 at 11:05 +0200, Denis Leroy wrote: > On 07/03/2009 10:03 AM, Thomas Vander Stichele wrote: > > As a further data point, I did the following: > > > > - read-cd cure.toc > > - write cure.toc > > - read-toc cure2.toc > > > > ie, reading a cd, writing it again, then reading the written CD. > > > > As you can clearly see from the attachments, there is an off-by-one > > error on the frame calculation somewhere. I'm going to assume it's in > > the reading part after comparing with EAC. > > > > In the bug tracker, I found > > https://sourceforge.net/tracker/?func=detail&aid=604751&group_id=2171&atid=102171 > > > > which looks like my bug. > > > > I'll attach my findings there. > > > > It would be nice to get this fixed, but meanwhile I'll work around it. > > I hope I get told though when this gets fixed :) Otherwise my workaround > > will get it wrong when it does. > > Thomas, I'll try to address this bug within next week, but it's tricky > as this is really in the parsing core of cdrdao, which unfortunately I > am not super familiar with. What is it parsing at that point ? subchannels ? I'm not 100% sure I've pinpointed the bug, I'm trying with more discs. I've found one disc where it actually gets 100% correct pre-gap lengths, which is annoying as it means that for now I don't even have a correct workaround. > > What is 'EAC' ? Exact Audio Copy, a Windows program considered by many to be the reference. I'm working on a cd ripper that at least quality-wise is comparable to EAC. > Also, have you tried the patch that is in bug 604751 first comment ? Not yet; it's obvious what the patch does, but I don't understand enough of the subclass code there for the various drivers and I doubt only the generic one would need fixing. And so far I'm not sure I"ve pinpointed the bug yet... Someone providing some confirmation would be good. Thomas -- Being hung over is like winning the lottery, except they pay you in regret! -- Flumotion - the only way to stream! http://www.flumotion.net/ |
|
From: j t <ma...@gm...> - 2009-07-03 21:53:33
|
On Fri, Jul 3, 2009 at 10:34 AM, Thomas Vander Stichele<th...@ap...> > I'm working on a cd ripper that at least quality-wise is comparable to > EAC. > Thomas Thomas, just a pointer in case you haven't already seen it: http://gna.org/projects/cued With kindest regards, Jaime |
Thanks for helping keep SourceForge clean.
X