|
|
Posted by Billy Joe on 09/25/12 11:25
Don M. wrote:
> "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).
That is the danger in doing BYTE offset cutting rather than FRAME offset
cutting. Worse yet, the unreliability of the source material - a
compilation, rather than an album rip.
The cue sheets may only contain time or frame counts pulled by the ripper
from the CDA data. That's not to say that the contributor of the cue sheet
did not actually compile the album from individual ID3ed tracks, while
capturing the time/frame data from the ripper. Clearly a no no to some
splitters, but FREEDB is, above all else, FREE!!
> 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.
Yes, it does do this, Don - and the bug mentioned previously is just that -
a bug. The math becomes kindergarten simple when there is absolutely
nothing in the file except the ripped frames and when the cue sheet is
accurate to begin with. I keep toying with this alternative, but it would
mean scanning the whole file first to confirm its composition - so I can't
convince myself to bother. (Sorry, my old school mind of "just 'cause you
say it's CBR don't mean I gotta believe it" ;-0)
> 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.
>
Not to beat a dead horse, nor an old war horse, I've used MP3DC primarily
because of the graphic display. With it I could quickly find silence and
listen to both sides of it. I have never used it with cue sheets - mostly
because I only reached for it when there wasn't one! I would happily
continue to use it in the same way.
>> 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...
>
I used CDex's Edit - "Copy album info to clipboard," to verify that the
FREEDB cue sheet is in complete agreement with the CD I was ripping. I also
assume that this is the method by which some contributors submit cue sheets
to FREEDB?
What I observed, when ripping in several different ways with FhG decoder,
was that the CDex play time listing did not change when the output clearly
did! This seemed mostly to be the amount of silence in individual tracks
versus album rips. None the less, inaccurate and undetectable by those of
use who would decompile the album.
>> 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,
Damn, once again I've chosen a poor set of words to convey my thoughts -
maybe the ex was right after all (lo these 32 years later, he says;-0)
I was trying to account for the 65 frame difference shown between MP3DC's
more accurate CBR calculation and my own GP algorithm. 32 of those frames
were computational differences, the rest were MP3DC's bug. Lacking the bug,
we'd have been 32 frames apart - barely one per track for the 34 tracks. So
I was actually strutting a little bit !!!!
None of the programs dealing with MP3 would (or should) split a frame. What
we will notice is silence padding to fill a partial frame at the end of a
track - which seems rare among my VBR rips, while it showed up often in the
FhG CBR rips, and it makes sense.
<snip>
If I haven't said thanks often enough, Don, let me add it sincerely once
again,
BJ
Navigation:
[Reply to this message]
|