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.

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!

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.

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.

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)

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

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.

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.

About your pcutmp3 tool.á I've been using it some more and have even recommended it to a few others on another forum; although I have told them that they should use this at their own risk.á Anyway, I've noticed that when I crop an mp3 encoded via fhg the lame_version gets set to 'LAME', when of course it shouldn't be, as it was never LAME to begin with.

QUOTE (Sebi replied with)

Understood. The thing is: Sample accurate splicing only works in conjunction with the "LAME tag". So, in order to cut accurately a LAME tag is inserted into the first frame of each of the generated mp3 files. Unfortunately the LAME devs designed this tag as they did -- meaning there's no good way of telling whether this tag is presend or not. So, in order to make pcutmp3 produce mp3 files so that most players recognize this tag it's necessary to embedd the character string "LAME" in there. Though, this may lead some applications to think that this file has been encoded by LAME.

IMHO the only GOOD way of checking the presence of the LAME tag is to check the CRC16 checksum of the tag. PCUTMP3 produces a *correct* CRC16 checksum according to the LAME tag specification whereas Foobar2K's fix-VBR-header-plugin *DOES NOT* -- just to mention that...

QUOTE (jaybeee asked)

I suspect you're a busy man, but I'd be happy to host your tool on my site if a couple of fixes/enhancements could be made: id3v2 support & the lame_version thing.

QUOTE (Sebi replied with)

Can't do. Time is really limited atm. Feel free to distribute the tool. Source code is included in the JAR archive. The part where all the magic is in (ScannedMP3.java) is a bit messy but I cleaned most of the other stuff. It should be easy to write your own interface or to add ID3v2 support.Sebi

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.

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...

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

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.

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

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.

QUOTE (Jojo @ Jan 6 2006, 02:51 AM)

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...

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.

QUOTE (Jojo @ Jan 17 2006, 01:36 AM)

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

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 ?

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

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 ?

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.

This post has been edited by Jojo: Jan 18 2006, 07:00

--------------------

--alt-presets are there for a reason! These other switches DO NOT work better than it, trust me on this.LAME + Joint Stereo doesn't destroy 'Stereo'

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