Posted by Don M. on 08/29/05 19:27

"Billy Joe" wrote in message news:ip6dnXYw5KBb1Y_eRVn-oA@adelphia.com...
>
> Here's what happens with FhG via CDex
> http://users.adelphia.net/~bjb1939/CDex_info.txt
>
> This a CDex 'Album Info" dump, enhanced (cluttered) with more stuff about
> the various programs.
>
> 1) "Frames cut by CDex" shows the sizes of individual files when ripped from
> this album.
>
> 2) "CDDA - MP3 offsets" shows the CDex (or FreeDB) cue sheet offsets vs.
> the MP3 offsets calculated by my algorithm. Note too that CBR calculations
> of the same cues produce virtually the same results. (reinforced by MP3CD's
> cut points).
>
> 3) "Frames cut by:" Shows the result files produced by "MP3DirectCut" and
> "Mp3 Cut"
>
> BY-the-way, this is a +2 tweak in "MP3 cut," as there in no pre-gap after
> the first track.
>
> FhG uses hex FF for silence, and seems a tad arbitrary in the application of
> it. So I've removed Hex FF from the silence test and added its count (as
> Null) to the analysis. Thus all cuts in the example are calculated, rather
> than "helped" by internal cues.
>
> The parenthetical values show the number of "silent" frames in that specific
> ripped track or section of the ripped album.
>
> Special note:
> While I do not mean to pick on MP3DirectCut (it has been my cutter of choice
> for years) it's having been handy, I've used it as a benchmark. This has
> revealed some points of interest.
>
> a) It's no better at calculating MP3 offsets from CDDA offsets that my
> little program ;-0)
>
> b) It has one bug which I've just found: the last frame of any cut track is
> duplicated as the first frame of the next track! Notice that, in this
> sample, MP3DC produces approximately the specified number of frames per
> track, so the "extra" frame is pushing other frames toward the rear (see
> following notes).
>
=========

As far as I can tell, MP3DirectCut has trouble cutting albums whose tracks have ID3 tag
(v1 or v2 or both). If tracks were stripped of tags before joining, MP3DC should do a
clean split, that is, spit out mp3 tracks with the same number of mp3 frames as the
original tracks (when using a cue sheet that reflects the original tracks, that is) or at
least give accurate sum of mp3 frames.
Some versions split better than others using the internal pause detection tool. I think
v1.32 is better than latter ones in doing that.
Another thing to consider with MP3DC: what you see is not always what you get, especially
the further one moves from the start, CBR included.

I did notice the "bug" you mentioned, in at least one version a while back. I've not used
MP3DC since to split albums where continuity from one track to the next is important (to
anal retentive people, of course :) More on this in the last paragraph.

> CDex does not go unscathed here either: No matter which way I rip the
> album, CDex always yields the came cue sheet!!! Yet, as we can see, the
> result file is not identical in each variation of the rip, so the cue sheet
> should change. Thus, not knowing which method was used to rip a file
> renders the cue sheet useless for frame accurate de-ripping.
>

Not sure what you mean by CDex yielding a cue sheet...

> Finally, note the unusual circumstance of this particular album. Time
> stamps suggest that there should be 134,181 MP3 frames. And, if we rip the
> CD to individual tracks, there are. However, when ripped to a single track
> there are only 134,116 frames. Oddly, MP3DC manages to dig up the missing
> frames when it reaches the last track??? How? 32 individual track
> formulaic discrepancies plus 33 frame duplications = 65 frames; the exact
> difference between the two programs.
>

I guess there is some internal rounding going on where the sum of the parts becomes bigger
than the whole, such as if a cut mark falls where a frame (i.e. your 192k/44.1, 626-byte
block) gets split (e.g. into 203 & 423). Instead of moving cut mark to the right or to
the left of the broken 626-byte block, the program splits where it is told and extends the
partial last and first blocks to the right and to the left in order to make 2 full frames
so you end up with 626 & 626 instead of 203 & 423 (bad frame condition). It's easier for
the programmer, who doesn't have to decide which track gets the frame in "dispute"; this
way both tracks end up not losing anything, but makes for bad listening of live
performances. The programmer may decide in a 10-616 break to "award" all 626 bytes to the
second track, I don't know. All I know is MP3DirectCut hasn't improved with newer
versions, quite to the contrary IMO.


Don

[Back to original message]