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

[senab]

There's only one thing that annoys me with this tool....

The fact it makes CBR files VBR. For instance when cutting a 192kbits CBR mp3, the first frame is 128kbits and the rest is 192kbits. This messes up my Rio Karma as for some reason it can't read the MP3 length properly... If anyone else would like to test this out. Btw I used Encspot to look at the file bitrates.

Other than that, great tool Seb


//EDIT... Spelling

This post has been edited by senab: Dec 18 2005, 21:33

[SebastianG]

There's only one thing that annoys me with this tool....

The fact it makes CBR files VBR. For instance when cutting a 192kbits CBR mp3, the first frame is 128kbits and the rest is 192kbits. This messes up my Rio Karma as for some reason it can't read the MP3 length properly...  If anyone else would like to test this out. Btw I used Encspot to look at the file bitrates.

I can't test pcutmp3 at the moment, but I think I know what's going on. It's most likely the consequence of both (pcutmp3 and your Karma-mp3-decoder) behaving a bit incompatible.

Yes, pcutmp3 currently produces a first audio frame which is usually very small followed by a subset of the original frames. This first frame solely contains some main data filling the bitreservoir for the next frame. But pcutmp3 fills the header frame (imho) appropriately (frame count, size of all audio frames in bytes, "INFO" tag indicating a CBR file.

The Karma firmware seems to get the bitrate informations from the first audio frame (when a header frame with a "INFO" tag is present). They could have also just evaluated the frame-count field of the header which won't lead to the problem you are experiencing.

A quick hack of pcutmp3 is possible to make most of the cases work with your Karma (making this reservoir filler frame as large as the other ones if possible). My time is currently very limited. This change may take a while.

However, the Karma firmware developer team should (imho) think about a better way of determining the bitrate / length (ie using the frame count from the header frame)

Sebi

This post has been edited by SebastianG: Dec 19 2005, 18:35