pcutmp3 tool, properly/perfect cut mp3 Options

[dignick]

Thanks sebi. Any plans to add ID3V2?

[SebastianG]

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

This post has been edited by SebastianG: Oct 2 2005, 13:34

[dignick]

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

CODE

writing "c:\edit\Cut\05 - Roman Flugel - GehtÆs Noch?.mp3" ...
Exception in thread "main" java.io.FileNotFoundException: c:\edit\Cut\05 - Roman
Flugel - GehtÆs Noch?.mp3 (The filename, directory name, or volume label syntax
is incorrect)
       at java.io.FileOutputStream.open(Native Method)
       at java.io.FileOutputStream.<init>(Unknown Source)
       at java.io.FileOutputStream.<init>(Unknown Source)
       at de.zebee.mpa.MainCLI.main(MainCLI.java:241)

Could pcutmp3 ignore this file or replace the problem character with a user-specified or default character so it doesn't interupt processing?

Thanks

This post has been edited by dignick: Oct 4 2005, 19:34

[SebastianG]

EDIT2:  On some characters i get things like

CODE

writing "c:\edit\Cut\05 - Roman Flugel - GehtÆs Noch?.mp3" ...
Exception in thread "main" java.io.FileNotFoundException: c:\edit\Cut\05 - Roman
Flugel - GehtÆs Noch?.mp3 (The filename, directory name, or volume label syntax
is incorrect)
       at java.io.FileOutputStream.open(Native Method)
       at java.io.FileOutputStream.<init>(Unknown Source)
       at java.io.FileOutputStream.<init>(Unknown Source)
       at de.zebee.mpa.MainCLI.main(MainCLI.java:241)

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

[dignick]

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.

[jaybeee]

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

[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

[Shade[ST]]

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

[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

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.

[SebastianG]

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

This post has been edited by SebastianG: Dec 21 2005, 09:18

[jaybeee]

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

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.

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

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.

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

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

This post has been edited by jaybeee: Dec 21 2005, 13:16

[senab]

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?

This post has been edited by senab: Dec 21 2005, 15:44

[SebastianG]

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

This post has been edited by SebastianG: Dec 21 2005, 17:28

[Jojo]

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

This post has been edited by Jojo: Jan 6 2006, 03:07

[PzyMazter]

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

[jaybeee]

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

[markanini]

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

This post has been edited by markanini: Jan 6 2006, 13:47

[Jojo]

Thanks sebi.  Any plans to add ID3V2?

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.

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.

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

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

I second that.

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

[jaybeee]

Thanks sebi.  Any plans to add ID3V2?

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.

True

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.

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'll have a play and see what I find.

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

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.

[Jojo]

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

[SebastianG]

Hello y'all !

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.

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.

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 ?

Sebi

This post has been edited by SebastianG: Jan 17 2006, 10:08

[Jojo]

thanks for your answer.

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

[dignick]

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

[markanini]

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