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

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.

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.

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

Yes.

QUOTE (jaybeee @ Jul 20 2005, 02:25 PM)

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

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

QUOTE (jaybeee @ Jul 20 2005, 02:25 PM)

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

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.

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

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.

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.

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.

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.

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.

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.

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:

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.

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)

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

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

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

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

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

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.

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

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.

- 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