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: mp3brfix (Read 10989 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

mp3brfix

Hi !

Long  story short: Simple framewise cutting of MP3 streams usually makes the first couple of frames of new files undecodable due to the bitreservoir. Appearently there are some decoders out ther that produce noise in this case (see this thread) or even refuse to play'em (like the first Final Scratch DJ Software). A friend of mine told me about the latter issue about 2.5 years ago and I created a small app which is able to "fix" those mp3 files.

Let me stress that the algorithm is destructive. If you split a large mp3 file, "fix" track 2,3,4,...  concatenate them again you won't get the original mp3 file since the critical frames that were undecodable are just silenced so that no decoder produces noise / clicks or refuses them anymore.

There are other options that are less destructive (ie proper splitting while accounting for the bit reservoir) but for now this seems to be the fastest / easiest solution (I don't have any time nor enough motivation atm to build a proper splitter.)

Since this is an audio related issue and me not having any webspace I thought it'd be a good idea to publish this tool here. I guess it's public domain now. (Java source code included)

Use it at your own risk.

Sebi

edit: the link provided here refers to the old version (0.94beta). Check my next message below for the newer one

mp3brfix

Reply #1 –
To add misery to your already unmotivaded splitter idea, my idea for a "proper" splitter can do the following:
  • Detect input delay/padding and account for when chopping.
  • All cuts will overestimage when sample boundary fall in the middle of a packet.
  • The output segments will make use of LAME tag delay/padding to eat up the overflow.
  • In MP3 files, if the target packet (or even packets past it) depends on the bit reservoir, the code will find the neatest way to solve the dependency with a single packet, but no more than 4095 samples' worth. For example, if previous packet fills the necessary amount completely, it shouldn't be difficult to force the side data such that the packet is silenced. For greater than one packet fill to the reservoir, the general idea is to collect as much data as target_frame and beyond depend on, and if necessary, squash it all together into maybe a single LAME tagfor the delay/cutting infp

How's that for "whoa".

mp3brfix

Reply #2 –
Here's a new version (0.95beta).
It comes with directory scanning support and a change in the bitreservoir handling for the first frame in case it contains a Xing/Info/Lame tag. (Note the parameter syntax has changed as well)

It hasn't been heavily tested, though.

Sebi

mp3brfix

Reply #3 –
Quote
  • In MP3 files, if the target packet (or even packets past it) depends on the bit reservoir, the code will find the neatest way to solve the dependency with a single packet, but no more than 4095 samples' worth. For example, if previous packet fills the necessary amount completely, it shouldn't be difficult to force the side data such that the packet is silenced. For greater than one packet fill to the reservoir, the general idea is to collect as much data as target_frame and beyond depend on, and if necessary, squash it all together into maybe a single LAME tagfor the delay/cutting infp

How's that for "whoa".
[a href="index.php?act=findpost&pid=306601"][{POST_SNAPBACK}][/a]


heheh
Just a side note: decoders who are aware of the Xing/Info/Lame tag frames completely discard the maindata section of those frames. So, you can't put missing maindata bits for the next frame in there. You HAVE to use a "silence frame" containing the important data for the next frame in its maindata section. This one frame could be made large enough (320 kbps) so that all necessary data fits in there to avoid the delay of multiple frames for non-lame-tag-aware-decoders.

But we could also rip/encode CDs properly the way we want the mp3s to be. So, IMHO, there's no need to invest too much time on something like this.

Sebi

mp3brfix

Reply #4 –
I was not referring to using the VBR packet for data recovery, but using the LAME delay/padding info to skip over packet(s) used for data recovery, in addition to the overflow samples when the cut doesn't fall on a packet boundary.

Also note that decoder delay is included in the padding, even though it is eaten from the beginning of the track. Account for that in further successive cut points.

I already invested a few hours into this when I was bored a few days ago, but it could use some polish, and also properly stuffing data into that silence packet. There would appear to be some dependency issues beyond that, or I am not stuffing the data properly, as the resulting cuts are not bit identical to the original ranges as decoded from the complete track. In fact, sometimes the differences show odd ripples now and then.

You're welcome to what you want with it, BSD license my parts of the code, yadda yadda. The files under the MPAHeader directory are modified from the source code here, no licensing info provided as far as I can tell. Maybe replace the packet parsing with your own code or something nicer? (Realized a bit late that code reads the whole file to memory...)

You are very correct about ripping properly in the first place. Idiots need to stop using MP3/CUE for "mix" CDs when there's already a proper gapless solution, and a range of gapless alternatives. (And hey, there's always lossless. )

mp3brfix

Reply #5 –
Quote
To add misery to your already unmotivaded splitter idea, my idea for a "proper" splitter can do the following:

<list removed>

How's that for "whoa".
[{POST_SNAPBACK}][/a]


If found some time to code such a tool. It does all that (sample granular cutting). But unfrotunately Foobar2k (v0.8.3) dosn't like encoder delays above 1152 or encoder paddings above 2304. Especially the low encoder delay limit is a sad thing 'cause a player has to support encoder delays of ca 3000 samples as well  to fully handle bit reservoir issues.

So ... IF a player supports that, this solution does not only allow perfect gapless splitting (without bit reservoir issues) but also perfect click-less playback at track boundaries !!! 

edit: I finished writing the app. It looks like it does what it's supposed to do. But playback is NOT gapless in Foobar v0.8.x due to its limited enc_delay value support.

edit: See [a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=35654]this thread[/url]. (Post #5 is about a hack to make it work with Foobar 0.8.3)

Sebi