From: jeff w. <we...@ya...> - 2012-04-10 12:36:47
|
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 ;-) --- 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. Thanks for your question! Jeff ________________________________ From: Brian Burch <br...@pi...> To: jeff welty <we...@ya...> Cc: "gwc...@li..." <gwc...@li...> Sent: Tuesday, April 10, 2012 2:42 AM Subject: Re: [Gwc-general] Invalid cdrdao toc file On 09/04/12 23:51, jeff welty wrote: > Hi Brian, > > I didn't get any new toc files in your message... > > I have tried both methods for creating the toc files, and it works > perfectly for me. > > Are the differences you are seeing less than 588 samples? If so, that is > expected because of the restriction that cdrdao tracks have to be > multiples of audio blocks in length. Sorry, Jeff! When I sent the last email I forgot to include the toc file built by your new version of markers.c. It is in-line at the end of my comments. Following your advice, I checked the differences and can see they are smaller than 588 samples, i.e. the two "gaps" are 262 and 76 samples respectively. I apologise for doubting you. You had mentioned this restriction earlier but I had forgotten it. I /thought/ you meant gwc would always start a new track on a boundary that is a multiple of 588. I grepped the source for 588 and found it only only in markers.c, defining the constant SONG_BLOCK_LEN. I could only find that constant used in two routines - move_song_marker and mark_songs. Both routines appear to be rounding the song marker boundaries to make them multiples of 588. I don't currently have a debugging environment to follow the logic any deeper, but my calculator says /none/ of the sample counters in the new toc are multiples of 588 (except zero, of course). I apologise for being a nuisance, but would you mind explaining to me how the rule has been applied in this particular case? CD_TEXT { LANGUAGE_MAP { 0: EN } LANGUAGE 0 { TITLE "The Doors" MESSAGE "Brians clean test" } } TRACK AUDIO CD_TEXT { LANGUAGE 0 { TITLE "part 1" MESSAGE "" } } FILE "/home/brian/gwc-test/export.wav" 0 38342303 TRACK AUDIO CD_TEXT { LANGUAGE 0 { TITLE "part 2" MESSAGE "" } } FILE "/home/brian/gwc-test/export.wav" 38342565 28204595 TRACK AUDIO CD_TEXT { LANGUAGE 0 { TITLE "part 3" MESSAGE "" } } FILE "/home/brian/gwc-test/export.wav" 66547236 50606219 > Jeff > > ------------------------------------------------------------------------ > *From:* Brian Burch <br...@pi...> > *To:* "gwc...@li..." > <gwc...@li...> > *Sent:* Monday, April 9, 2012 2:40 AM > *Subject:* Re: [Gwc-general] Invalid cdrdao toc file > > On 08/04/12 23:36, jeff welty wrote: > > Hi Brian, > > > > Thanks very much for the more detailed info. I was able to reproduce the > > problem, and it is one nasty bug. I guess everyone must've switched over > > to using the song marker pairs. BTW, the marker pairs idea allows you to > > have gaps between songs, some lead-in audio (like when the the needle > > hits the vinyl ;-) ), and some trail out audio. It gives you more > > control on what segments of audio you want to appear on the CD tracks. > > > > Another bit of important trivia, audio tracks must be integral numbers > > of audio blocks, which are 588 samples in length, so if you are doing > > math with song markers, you'll find small differences because GWC will > > create the cdrdao file with the track lengths to the nearest audio block. > > > > I have patched up the markers.c source code, and it is attached. > > Sorry to bring bad news, Jeff, but I have just built and tested your new > source module. It looks to me as if you have nearly fixed the bug, but > there is still a bit more to do. > > It seems to me that you haven't disabled the marker pair "track > separator logic" and so the toc is not inclusive of every sample... > > i.e. start_track_n+1 != (start_track_n + length_track_n) > > Here is the toc built by your new code using the same wav and .gwc file > as my test files below. You should compare it to the toc I built by hand > to see what I think ought to be the "right answer". > > I won't start debugging your code unless you are too busy to do it > yourself - I am sure you are so familiar with it you'll come up with a > fix in a fraction of the time it would take me! > > Regards, > > Brian > ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Gwc-general mailing list Gwc...@li... https://lists.sourceforge.net/lists/listinfo/gwc-general |