|
|
Posted by Billy Joe on 08/26/05 18:19
Don M. wrote:
> "Billy Joe" <see.id.line@invalid.org> wrote in message
> news:p5ydnYhW-o3llpPeRVn-uA@adelphia.com...
>> http://users.adelphia.net/~bjb1939/MP3cutsV1.2e.zip
>>
> =========
>
> The FhG album I merged with MP3Merger split correctly. I had to
> lower the silence minimum from 0.75 to 0.18s to get the last 8+
> minutes be recognized as 2 tracks. All splits were within 4 frames
> of original tracks, except track 1 (33 frames bigger) and the last
> track (7 frames shorter). Anyway, the split album is "validated"
> when I do a freedb lookup.
>
>
> Don
The CDex-LAME ripper, in the few albums I've tested with so far, tends to
increase CBR track one by 7 or 8 frames and decrease the last track by the
same amount when compared with a rip of the same album in VBR. This is what
led me to include the "Offset" entry just below the "Tweak." Thirty-three
frames is quite an addition! (I'm guessing the tweak for this file is
different than -2 and that the 33 offset is probably needed as an entry).
Which FhG codec are you using? I have version 1.2 build 63i installed. I
notice it has individual settings for default channel settings per bit rate.
If I can use the same codec as you, I'll see if I can figure out what it's
adding in the first track, and whether the FhG tweak is different.
Out of curiosity, did you try splitting the file with another program using
a cue sheet?
http://users.adelphia.net/~bjb1939/MP3cutsV1.2f.zip
This rev has changes for overshoots (truncated frames). It now rescans the
body of the truncated frame looking for other cues. Also some changes to
ID3v1 capture. I doubt it will fix anything regarding the ZIP and OOM
error. However, the Out of memory problem comes from my trying to jam too
much into the edit box. Repeated Hex Dumps cause VB to consume its
allocation. The changes might reduce, or even eliminate the hex dumps, if
they were caused by overshooting a frame.
BJ
Navigation:
[Reply to this message]
|