pcutmp3 tool, properly/perfect cut mp3 Options

[SebastianG]

Hi !

I got quite a few PMs about the mp3 splitter (read more here). Because of that and the fact that it seems to be doing what it's supposed to I decided to make the current beta version public.

A Java Runtime Environement 1.4 or higher.is needed. You can call the application in the commandline via:
java -jar pcutmp3.jar <parameters>
(Leave parameters blank to see a help screen)

Splitting with a cue sheet is pretty simple. Here's an example:
java -jar pcutmp3.jar --cue something.cue something.mp3

WARNING:
Your player needs to properly support the LAME tag. If it doesn't you'll hear gaps. I tested it with Foobar 0.8.3 and Foobar 0.9 beta 5. Unfortunately the older one ignores encoder delay values above 1152 in the LAME tag (edit: see post #5 for Foobar 0.8.3). Since pcutmp3 usually creates mp3 files with encoder delays of around 2000 samples it won't work in Foobar 0.8.3. In combination with Foobar 0.9 beta 5 it works like charm. WinAMP + otachan's in_mpg123 + some good output-plug probably also works fine. So, use this app only if it makes sense to use it. The number of players which properly interpret the LAME tag is pretty low !! If your player does you can use pcutmp3 to do sample granular cuts.

How it works:
This app analyzes the source mp3 file and its Xing/Info/LAME tag and allows cutting it at *any* positions through the use of the LAME tag's encoder_delay/padding fields. It generates for each track you crop out of the large source file a new Xing/Info/LAME tag frame filled appropriately and resolves the problem of missing bitreservoir data via a "silence frame" (holding the missing data) that directly follows the Xing/Info/LAME tag frame. This additional delay (due to this "silence frame") is also compensated via the encoder_delay setting which explains the high values it produces (576...2879). It should be possible to rejoin files losslessly (not yet implemented).

Sebi

direct link to version 0.95 beta (I'm sorry, this is a dead link)
Feedback is appreciated.

This post has been edited by SebastianG: May 31 2008, 10:29

[SebastianG]

dignick: Did you try the latest version? I thought I already fixed the seektable generation (see post#4)

The only pcutmp3 bug I know of is it may choke on previously "unproperly" cut files.

BTW: I was thinking of doing a partial rewrite when I've more time on my hands. The code where all the magic takes place (ScannedMP3.java) looks kinda messy currently.

So I posted it as a bug, which they fixed, but the problem was really with the mp3 files themselves

The seektable in those files seem to be incorrect.

Can you elaborate? I can't believe that incorrect seektables would cause the behaviour you described. It's probaby the usually higher "ENC_DELAY" values from the LAME header that cause XBMC to do weird stuff.

Sebi

This post has been edited by SebastianG: May 17 2006, 18:34

[Jojo]

I can't believe that incorrect seektables would cause the behaviour you described. It's probaby the usually higher "ENC_DELAY" values from the LAME header that cause XBMC to do weird stuff.

yep, iTunes does the same. I've cut a song where there is silence up in front, but iTunes plays the last few frames before the silent part. foobar is getting ir right though