Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: pcutmp3 tool (Read 285872 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

pcutmp3 tool

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.

pcutmp3 tool

Reply #1
Try zipping it, allowed upload file extensions are restricted to specific list.
Microsoft Windows: We can't script here, this is bat country.

pcutmp3 tool

Reply #2
Quote
Try zipping it, allowed upload file extensions are restricted to specific list.
[a href="index.php?act=findpost&pid=314306"][{POST_SNAPBACK}][/a]


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

Sebi

pcutmp3 tool

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

pcutmp3 tool

Reply #4
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)

Code: [Select]
before:
00007670:  E6 04 C1 E0  08 03 CE 03  C2 85 C9 7C  21 81 F9 80
00007680:  04 00 00 7F  19 85 C0 7C  15 3D 00 09  00 00 7F 0E
afterwards:
00007670:  E6 04 C1 E0  08 03 CE 03  C2 85 C9 7C  21 81 F9 40
00007680:  0B 00 00 7F  19 85 C0 7C  15 3D 00 09  00 00 7F 0E


The relevant lines of code are (mp3.cpp):
Code: [Select]
if (enc_delay>=0 && enc_delay<=1152 && enc_padding>=0 && enc_padding <= 2304)
{
       pTagData->enc_delay=enc_delay;
       pTagData->enc_padding=enc_padding;
}
else
{
       pTagData->enc_delay = -1;
       pTagData->enc_padding = -1;
}

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

pcutmp3 tool

Reply #5
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.

pcutmp3 tool

Reply #6
Quote
(1) Does the 'crop' functionality work now (sorry, I'm at work and cannot d/l this yet)?
[a href="index.php?act=findpost&pid=314876"][{POST_SNAPBACK}][/a]

Yes.
Quote
(2) If you could losslessly rejoin these split/cut files then that would be great too.
[a href="index.php?act=findpost&pid=314876"][{POST_SNAPBACK}][/a]

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

Quote
(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.
[a href="index.php?act=findpost&pid=314876"][{POST_SNAPBACK}][/a]

OK.

Sebi

pcutmp3 tool

Reply #7
Quote
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.[a href="index.php?act=findpost&pid=314872"][{POST_SNAPBACK}][/a]

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

pcutmp3 tool

Reply #8
Quote
Quote
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.[a href="index.php?act=findpost&pid=314872"][{POST_SNAPBACK}][/a]

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.)
[a href="index.php?act=findpost&pid=314882"][{POST_SNAPBACK}][/a]


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

pcutmp3 tool

Reply #9
Quote
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.
[a href="index.php?act=findpost&pid=314897"][{POST_SNAPBACK}][/a]

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.

pcutmp3 tool

Reply #10
Quote
Quote
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.
[{POST_SNAPBACK}][/a]

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.
[a href="index.php?act=findpost&pid=315522"][{POST_SNAPBACK}][/a]


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.

[a href="http://gabriel.mp3-tech.org/mp3infotag.html]http://gabriel.mp3-tech.org/mp3infotag.html[/url]

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

pcutmp3 tool

Reply #11
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.

pcutmp3 tool

Reply #12
Quote
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.
[a href="index.php?act=findpost&pid=321211"][{POST_SNAPBACK}][/a]


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

pcutmp3 tool

Reply #13
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.

pcutmp3 tool

Reply #14
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

pcutmp3 tool

Reply #15
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

pcutmp3 tool

Reply #16
Commandline still says v0.92b.
"ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD"
        - Oceania Association of Autonomous Astronauts

pcutmp3 tool

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

It should work now.

Sebi

pcutmp3 tool

Reply #18
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

pcutmp3 tool

Reply #19
Quote
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.
Thats my only request atm, I can manage without a gui

Thanks
[a href="index.php?act=findpost&pid=329297"][{POST_SNAPBACK}][/a]

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

pcutmp3 tool

Reply #20
Quote
Quote
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.
Thats my only request atm, I can manage without a gui

Thanks
[a href="index.php?act=findpost&pid=329297"][{POST_SNAPBACK}][/a]

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).
[a href="index.php?act=findpost&pid=329301"][{POST_SNAPBACK}][/a]


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.

pcutmp3 tool

Reply #21
Quote
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
[a href="index.php?act=findpost&pid=329297"][{POST_SNAPBACK}][/a]


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

pcutmp3 tool

Reply #22
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

pcutmp3 tool

Reply #23
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

pcutmp3 tool

Reply #24
Very minor point:

Code: [Select]
--out <sheme>           specify custom naming sheme where
                        %s = source filename (without extension)
                        %n = track number (leading zero)
                        %t = track title (from CUE sheet)
                        %p = track performer (from CUE sheet)
                        %a = album name (from CUE sheet)
                        Default is "%s-%n"


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

Thanks for this tool.
I'm on a horse.