|
|
Posted by Billy Joe on 08/28/05 23:29
Don M. wrote:
> "Billy Joe" <see.id.line@invalid.org> wrote in message
> news:TKadncWWDZuxwJLeRVn-2A@adelphia.com...
>>
>> http://users.adelphia.net/~bjb1939/MP3cutsV1.2f.zip
>>
> ==========
>
> [Revise Cuts] and [Cut] are not available after I paste the freedb
> cue sheet into the work area. {Album Title} and {Artist} are filled
> in automatically with a click on the right hand side, which is neat,
> but [Check Frames] is activated instead of the other two.
>
>
> Don
http://users.adelphia.net/~bjb1939/MP3cutsV1.2g.zip
Hopefully solves what you encountered. May do some other stuff too ;-)
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).
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.
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.
As to one algorithm being more accurate than the other, I'd go with MP3DC's
CBR algorithm over the mildly vacillating "MP3 cut's" more general purpose
algorithm - but then, mine works as well in both cases ;-0)
Back to basics: CBR & VBR cuts are always gonna be approximate and any
coincidence with reality is merely that:-( Neither program cuts the
compilation to the original frames - and neither could have, as CDex lied
about the cut points! Talk about an exercise in futility?? Ah well, it
works as well as most things - close is good enough ;-0)
BJ
[Back to original message]
|