Re: [Gwc-general] Invalid cdrdao toc file

[Brian B. <br...@pi...>]

On 11/04/12 02:28, jeff welty wrote:
> At this time, I'm going hold off on another release --- cdrdao pads
> zeros at the end of the track to get the track to a multiple of a block
> length. I suspect that has always been the behaviour. So please inform
> the ubuntu folks that this is good to go.

OK, Jeff. I have generated a patch file and will upload it soon (the 
whole source for markers.c is already appended to the bug report).

> I'm guessing too that your problem CD's have to do with cd media
> quality, write speed and perhaps hardware. My personal preference has
> been to find CD-Rs manufactured by Taiyo-Yuden

Yes, that is the brand I switched to about 2 years ago. I also threw out 
the cd writer that came with my machine and invested in a much better one.

> http://www.best-dvd-burning-software-reviews.com/best-blank-dvd-media.asp
> I always burn at the lowest write speed possible, because my
> understanding is when a CD-R is burned, it literally melts a little spot
> of dye to allow the reflective layer to be exposed for the desired bit.
> The faster the cd is spinning, it seems, the more centripidal force is
> going to allow the melted dye to spread over to the next cd track, and
> the laser could have a little more trouble burning through the extra
> dye. That's just my hypothesis, I don't know for sure if it's valid, but
> I figure if I spend multiple hours preparing data for a CD, I can wait
> an extra 30 or 40 minutes for it to burn...

I agree with you, although I normally write at 4x speed (a lot less than 
the 52x maximum). I think I'll follow your recommendation in future.

Incidentally, my "bad" CD's suffer from the player being unable to read 
the toc - hence my questions. My player reports "no disk" or "err" 
status when the drawer has closed. However, this cannot be caused by 
incorrect boundaries on the toc entries, because the disk will 
eventually play if I keep putting it back in after each error.

> ---
>
> In the first implementation of song markers, I wanted the user to have
> full control on the resolution of the start and end of tracks. There may
> be cd formats in the future that aren't limited to block lengths...
>
> I'm contemplating a function to adjust the song markers to block
> segments though, because of the padding behaviour of cdrdao. If you
> wanted gapless cd's, those padded zeros might cause an audible click.
> This is going to take some extra coding and I'll want to spend a little
> more quality time on it than I currently have in my free hours outside
> of work and family time
>
> Cheers,
> Jeff
>

That sounds like a useful way to deal with this issue. I'll watch out 
for its release. Thanks again for all your help and advice.

Regards,

Brian

>
>
> ------------------------------------------------------------------------
> *From:* Brian Burch <br...@pi...>
> *To:* jeff welty <we...@ya...>
> *Cc:* "gwc...@li..."
> <gwc...@li...>
> *Sent:* Tuesday, April 10, 2012 10:05 AM
> *Subject:* Re: [Gwc-general] Invalid cdrdao toc file
>
> On 10/04/12 13:36, jeff welty wrote:
>  > Hi Brian,
>  >
>  > No problem on the questions, questions are always good. Things get
>  > better when people are asking questions :-) In fact, I just caught
>  > another tiny bug because you asked this question.
>  >
>  > Tracks can start at any arbitrary position in the wavefile, cdrdao is
>  > just going to start copying data at that exact position in the wavfile
>  > to the CD. It is the length of the track that is restricted to multiples
>  > of 588 bytes.
>  >
>  > The logic in GWC for creating the cdrdao toc file goes like this:
>  >
>  > 1) The track start position will always be *exactly* at the song marker
>  > or at 0 in the case of the first track if you use
>  > the non-paired markers method.
>  >
>  > 2) compute the requested length of the track requested by using the next
>  > song marker or last audio sample if no more song markers.
>  >
>  > 3) round the requested length to the nearest 588 sample block
>  >
>  > 4) output the start position, and the rounded length to the toc file.
>  >
>  > The logic was set up like this because I though in most cases it was
>  > probably more important to get the start of the track positioned exactly
>  > where the user wanted it, and take the rounding error at the end of the
>  > track. The worst case would miss the song marker at the end of the track
>  > by 0.0067 seconds, probably not noticeable ;-)
>  > ---
>
> Your explanation is very interesting.
>
> My CD player is quite old and fussy about disks adhering to the original
> standards, but most of my CD's play OK. However, it is temperamental
> about playing some of those I made about 18 months to 3 years ago. I
> have always thought this problem was a combination of [media quality +
> writer quality + writer speed].
>
> My more recent disks are almost always accepted first time. I wonder
> whether the "old disk" problem has something to do with the old version
> of gwc, which was happy to write a toc that didn't put tracks on
> boundaries of 588 samples? Perhaps a newer version of cdrdao has logic
> to compensate for un-rounded tracks? Perhaps my 18-month-old cd-writer
> firmware handles the toc more gracefully than the drive I used before?
>
> Whatever the reason, my current production procedure generates playable
> CD's from the non-rounded tocs that I've edited manually, although other
> people might not be so lucky.
>
>  > I just noticed all your track lengths are odd numbers. Not good, because
>  > multiples of 588 must be even numbers. The code is outputting the length
>  > as (start - end), which is wrong, it should be (start-end+1). I wonder
>  > what cdrdao does with that, does it truncate or round the length. It
>  > could cause the actual track length to be 0.018 seconds shorter than
>  > desired in the worst case if it truncates. Still not noticeable, but
>  > still wrong.
>
> Are you intending to release a patch that fixes both problems? If yes,
> would you like me to test it? Would you like me to add it to my ubuntu
> bug report when I mark its status as "patch available"?
>
>  > Thanks for your question!
>  > Jeff
>
> One more question while you have the logic in your mind... why doesn't
> gwc deal with this boundary-rounding issue at the time it is creating
> the individual song marker? As you said, 588 samples is only 18
> milliseconds, so no harm would come if it were to enforce alignment of
> the new marker on a 588-sample position. Then, if you tried to drag the
> marker along the recording, it could just jump to the next valid
> position... but perhaps that is more complex and not worth the effort of
> implementing?
>
> Regards,
>
> Brian
>
>