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.

Try zipping it, allowed upload file extensions are restricted to specific list.

Okay. Thank you for the tip.
I finally took the chance to activate my university homepage.
The link should work.

Sebi

0.91b -> 0.92b:
- fixed seek table generation (VBR tag)

For those who use Foobar 0.8.3 and want it to be tolerant enough (in terms of enc_delay values) so that mp3 files that pcutmp3 produced are supported:

Close Foobar 0.8.3 if it's open
Grab a hex editor and open foo_input_std.dll
At offset 767f (hex) there's "80 04 00 00" (if not you've probably the wrong version. Stop here!)
Change it to "40 0B 00 00"
Save it
Start Foobar 0.8.3

That did it for me. (Yay!)
(You probably have to reload file infos to get the correct enc_dlay/padding values)



The relevant lines of code are (mp3.cpp):

By chaning "80 04" in the hex editor to "40 0B" you are replacing the 1152 in the if-statement with 2880. This seems to be some kind of validity test to prevent misinterpreting data which IMHO should be done via checking the LAME-tag's CRC16 checksum.

Please don't blame me if something goes wrong. Do it at your own risk.

Sebi

Excellent work SebastianG. I look forward to having a play with this beta version, and amending foobar.

A few things:

(1) Does the 'crop' functionality work now (sorry, I'm at work and cannot d/l this yet)?

(2) If you could losslessly rejoin these split/cut files then that would be great too.

(3) Re. your 'Warning 2' statement in your first post: I think you should make it override it whenever it doesn't find 'index 01 00:00:00', but add an option for the user not override it if they prefer.

Many thanks for this.

Yes.

Will come. But don't expect this feature too soon.


OK.

Sebi

VBR tag usually has the CRC disabled.

Another method of validation is to check for the "LAME" or "GOGO", like the VBR tag parser I borrowed for the example splitter I posted before... Hmm... (Although, this would break older tags, since this field is supposed to identify the encoder, and since foobar2000 does not assume the encoder when generating a new VBR tag, it leaves the entire string null.)

I guess we agree on that there isn't a good way of determining wheter a LAME tag is present or not.
My proposal would be to verify the CRC16. But I'm aware of that Foobar's FixMP3 header plugin creates an all-zero "LAME tag" with only enc_delay/padding set.

Sebi

There is no way to verify the CRC16 if the tagger does not create a packet which uses it, and I am not aware of any tagger which creates a packet with CRC16 enabled for the VBR header. I am not even sure if LAME does this if you explicitly enable CRC during encoding.

I think you got something wrong. I was talking about the LAME tag's CRC16 checksum (the last 16 bit of the tag - ALWAYS present in a LAME tag) which covers all previous bytes including the frame header. LAME always produces a "correct" CRC (though you have to do things differently compared to the optional CRC16 which folows directly the frame header (if the protection bit is zero) and only covers the last 2 bytes of the header and the side info section).

There's no way of signalling whether this field is valid or not (via a flag somewhere). It's either correct or not. To prevent misinterpreting data I proposed that this CRC16 checksum should be checked. This seems to be the best approach. I don't like the idea of testing the first four characters of the LAME tag if it matches "LAME" or "GOGO" since the specification only says that these four characters are just identifying the encoder and are NOT a static marker (indicating the presence of a LAME tag) . It could be anything.

http://gabriel.mp3-tech.org/mp3infotag.html

BTW: Since pcutmp3 almost always produces an additional silenceframe as first music frame (containing important main data bytes for the following frame) I forced creation of such a frame for all situations (not yet released) carrying some more meta informations (10 bytes don't hurt). Identifying such a frame is simple. Right behind the side info block this is following:

4 ASCII charactsers: "PCUT"
1 byte: PCUT tag revision (currently zero)
5 bytes: 40 bit big-endian integer named "absolute start sample"
(identifying the absolute start sample in the original encoding)
(variable amount of bytes) padding via ASCII character 'x'
(variable amount of bytes) main-data bytes for the following frame

bye,
Sebi

Thanks for this little program, could prove to be very useful. I too would love the lossless rejoin feature if possible.

I've noticed that it seems to write weird values in the ATH type field in the LAME tag. These don't match the value from the original mp3 file.

I would agree that checking for the strings LAME or GOGO to identify the existence of the LAME tag is not a great idea. Particularly because ACMEnc also writes LAME tags and this will write anything into those four bytes, whatever the user specifies to identify the codec they have used. It is a shame that foobar2000 doesn't write the Info Tag CRC at the end of the LAME tag because everything else I know of that writes a LAME tag sets this value so it might otherwise make a good test for the existence of a LAME tag.

If you're right, then it's due to a bug. The only thing that I intend to change is the encoder delay / padding and the RG data. What tool did you use to check that ?

Sebi

I used LameTag.exe. On the file I tested the following were changed: ATH Type, Encoder Delay and Padding, Music Length and InfoTag CRC, all of which make sense except for the ATH Type. The RG wasn't changed but it wasn't set in the file I tested anyway.

OK. I found the bug. (I'm also trying to set the no-gap bits which are located in the same byte the ATH setting is stored in to zero. The lower 6 bit have been taken from one of the lame tag CRC bytes instead of the original ATH byte)

I'll soon anounce an update in this thread.

Thank you, phwip, for reporting this.

Sebi

changes (0.92b -> 0.93b)

- fixed lame tag bug (ATH meta information was wrong)
- proper handling of the no-gap meta informations in the LAME tag
- marks the silence frame (which only carries data in its main data section) as such and includes some meta informations. This allows rejoining of files automatically (in the future)
- if mp3 source file is not given the file reference in the cue sheet is evaluated
- added option "--dir" to specify the output directory
- when splitting mp3 files according to a cue sheet the first track will now also always include the part prior index 1 (if greater than 00:00:00)
- error message (could not open source mp3) is now telling you the filename
of the file it tried to open.

http://homepages.upb.de/sgeseman/pcutmp3.jar

@moderators: This thread should probably be moved to some other forum.

Sebi

Commandline still says v0.92b.

Damn ...
(I havn't correctly updated the symbolic link, sorry!)

It should work now.

Sebi

Are you still working on this sebi?
I've got quite a few things waiting to be split, but I'd really like the tagging done for me, because it can get quite tiresome entering it all by hand. And as far as I know, your still the only one who has made a splitter that does its job properly
Thats my only request atm, I can manage without a gui

Thanks

If you are a foobar2000 user, just load the cue sheet with the tags in a new playlist then put the files from the splitted image file below (in the correct order), select the whole playlist and right click>Tagging>copy info (in fb2k0.9beta).

Thanks, that will help a lot! This splitter should be all over instead of the many that only do half a job. Anyway. Thanks again.

Hi! To answer your first question: No, currently not. I agree that ID3 / APEv2 tag support would be a great idea and the implementation of it should not be too complicated (just a bit time consuming). I'll probably look after it the next week-end.

bye,
Sebi

Available options in v.93b are:
--cue cue-filename split source mp3 via cue sheet
--crop t:s-e[,t:s-e[]] crop tracks manually, t = track#
s = start sample (inclusive)
e = end sample (exclusive)
--out "sheme" specify custom naming sheme where
%s = source filename (without extension)
%t = tracknumber (leading zero)
Default is "%s-%t"
--dir <directory> specify destination directory
Default is the current working directory

It would be great if the 'crop' option allowed the user to enter a time in minutes &/or seconds.

Thanks Sebi

changed 0.93b -> 0.94b (not heavily tested)

- now interpreting of PERFORMER and TITLE commands in CUE sheets
- ability to write ID3 tags (only ID3v1.1, tag(s) of source file is/are currently ignored)
- new variables for naming sheme (artist, album and title, note: tracknumber %t changed to %n)
- ability to set/override artist and album via commandline
- ability to specify the start/end time via [XXm]YY[.ZZ]s as well when cropping manually

All the links point to the new version now.


Sebi

Very minor point:



"sheme" should be "scheme". Two separate uses.

Thanks for this tool.

Thanks sebi. Any plans to add ID3V2?

If I manage to find a good implementation of ID3v2 in Java, then it should be a matter of a few minutes to add ID3v2 support. Frankly, I wasn't that pleased with the things I found when I looked for ID3 code in Java (might be me not looking at the right places) so I quickly wrote some simple ID3v1.1 stuff.

BTW: The source code is always included in the JAR package. So, if someone feels like improving MainCLI.java and/or adding ID3v2 / APEv2 support I'd be fine with it.

@Synthetic Soul: thanks for pointing out that I should've used "scheme". I already silently updated the 0.94b version two days ago.

Sebi

Quickly looking around, the most stable project written in java appears to be MP3Info. Don't know if this helps. Foobar works fine to copy the tags until you include id3v2 in pcutmp3, so i'm not trying to put pressure on you, it would just be nice to see it.

One feature request that I have though, particularly if you do include id3v2 support, is the ability to save preferences. Would be much easier to just type java -jar pcutmp3.jar --cue "file" and it to split using pre-specified options, for example the file naming scheme.

Thanks again sebi, wicked app.

EDIT: Stupid me, don't need preferences when you can type a batch file!

EDIT2: On some characters i get things like
Could pcutmp3 ignore this file or replace the problem character with a user-specified or default character so it doesn't interupt processing?

Thanks

Oh, I did not think about characters (like '?' and '*') some operating systems don't like in filenames. This will be fixed of course soon.

bye,
Sebi

Forgotten to mention this before, if you burn tracks you split with pcutmp3 to an audio cd using foobar, it plays back gapless, which is good, and the only reason I can see that you would want to merge tracks back together for.

Sebi - been using the tool for a while now and it's very useful and very good; esp now with the ability to specify time in the 'crop' fucntion. Any future enhancements planned, like the id3v2 support?

Thanks

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

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

The karma dev team will not be developing a discontinued product, I think.

It works fine with native VBR mp3's, just not CBR. I'll try and have a look at Pcut and see if I can hack it and change it.

Let me give you a starting point how one can fix that:
Goal: Increasing the size of the bit reservoir filler frame to match the CBR bitrate.
How 2 carry it out: Let the for loop in constructReservoirFrame start at the appropriate bitrate-index in case of isVBR being false. This index could be derived via the field avgBitrate (in kbps).

Although this would not be too time consuming I can't handle it myself right now.

Your help is appreciated

Sebi

he he, I asked Sebi a similar question the other day too.



@Sebi - hope you don't mind me quoting you. If you do mind, let me know and I'll remove it.

So senab, if you are up for enhancing this little tool then I'd be very happy too.

OK, let me have a look and I'll post what I've done later...


Just a quick question Sebi, in ScannedMP3.java, in the for loop in constructReservoirFrame, what is the variable bri?

bri = bit rate index ... this is an index into the well known bitrate table.
This index is part of the 32 bit frameheader and defines the frame's size in conjunction with the padding bit. IIRC there's a FrameHeader class which might be helpful here.


Sebi

does it also work when cutting CBR non Lame files? Let's say FhG? Will those files get a Lame Header or what?

thanks

Edit: works great with VBR files. However, I noticed that the Music CRC doesn't match with the actual Music CRC. The original file is fine. The Lame-Header CRC matches...

I cannot seem to get files I split using this tool to play in the Karma correctly at all, they seem to skip the first frame entirely (sounds like it skips a whole second).

Has anyone figured out why? I guess I'm not very technically understanding of how the Karma works..

Jojo - see my post on Dec 21 2005, 12:15 PM.
It does cut CBR files ok (and FhG), but as I say, and as Sebi says too, it 'changes' the file to VBR, and adds the values 'LAME' to the lame_version data field.

It's a shame Sebi hasn't got time to look at this tool some more to maybe make it into a real contender for splitting files. I mean I still use it and like it, but maybe a few tweaks to add id3v2 support & sort out the the lame_version thing would be really useful and perhaps can more appreciation from a wider audience.

senab said he was gonna have a look at the code. If anyone else with java coding experience would like to have a play I'm sure many peeps would be happy

Also if someone could make a GUI that would be nice.

i don't think that is the most important task for now, since there are plenty of other programs out there you can use for that purpose.


thanks. What about the CRC issue I've reported? I'd like to know if that is a bug (most likely it is), because I wanted to split a bunch of stuff...


I second that.

@ all
has someone tried http://mp3splt.sourceforge.net/

True

I'll have a play and see what I find.

Yep. It's good. It was the first lossless splitter I used. No install on the command line version - which I prefer actually. But I don't think it's quite as good as Sebi's frame splitting code, i.e. not as accurate. But it is much more stable/tested/experienced etc.

here is another little bug: pcutmp3 assumes that every cue sheet starts at 0:00.00, therefore, if you have a cue sheet that starts at 0:05.00 for instance, pcutmp3 will still start to cut @ 0:00.00

Hello y'all !


Yes. pcutmp3 simply defaults to an encoder delay of 576 samples and writes the LAME tag. The LAME tag is really an intergral part of the whole pcutmp3 idea ... So, it's added if it wasn't there before and this is being done with the "LAME" string as some kind of LAME-tag marker for maximum support. This of course might fool some applications to think the mp3 has been encoded via LAME. As I said before, I don't think there's a better way of doing things here because of the LAME tag format specification not specifying any good way of determining its presence.


This is intentional. According to the LAME tag specification the Music CRC is something that should not be altered. If we don't alter it, this Music CRC serves as an ID with which it is possible to automatically gather pieces of the same original track. This and the special PCUT tag together allows automatic rejoining. Something for the future development.


This is intentional as well. I'm not a fan of throwing anything away. The CUE split function was supposed to partition the original mp3 without loosing the pregap. This I thought makes most sense, doesn't it ?

Sebi

thanks for your answer.

I guess it does make sense, however, I changed a cue sheet and just wanted portions of a song. That is no problem when being done in the middle of the file, however, since it was at the beginning I ran into trouble. I ended up adding an extra track to the cue sheet and that worked like a charm.

Anyway, heads up for your great program. Thank you.

Nice to see this is staying alive. It's great even without id3v2 tagging, and yes I just create the tags from the filename afterwards, it takes me about an extra 10 seconds, so it isn't particularly important for me.
I use it for all my cue's, a batch file in the context menu cuts any cue with one click.
I hope it gets improved by someone else and gets the recognition it deserves because it beats eveything else IMO.
Thanks again sebi and anyone else who may be working on it

Could accuracy of the cut itself, that is, letting it be shifted around in time, be sacrifised for getting smaller padding values?