IPB

Welcome Guest ( Log In | Register )

> Upload forum rules

- No over 30 sec clips of copyrighted music. Cite properly and never more than necessary for the discussion.


- No copyrighted software without permission.


- Click here for complete Hydrogenaudio Terms of Service

 
Reply to this topicStart new topic
mp3brfix, to correct bitreservoir issues
SebastianG
post Jun 15 2005, 22:43
Post #1





Group: Developer
Posts: 1318
Joined: 20-March 04
From: Göttingen (DE)
Member No.: 12875



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

This post has been edited by SebastianG: Jun 21 2005, 14:58
Attached File(s)
Attached File  mp3brfix.zip ( 20.63K ) Number of downloads: 558
 
Go to the top of the page
+Quote Post
kode54
post Jun 16 2005, 18:28
Post #2





Group: Admin
Posts: 4623
Joined: 15-December 02
Member No.: 4082



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".
Go to the top of the page
+Quote Post
SebastianG
post Jun 21 2005, 14:54
Post #3





Group: Developer
Posts: 1318
Joined: 20-March 04
From: Göttingen (DE)
Member No.: 12875



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
Attached File(s)
Attached File  mp3brfix.zip ( 23.93K ) Number of downloads: 608
 
Go to the top of the page
+Quote Post
SebastianG
post Jun 23 2005, 12:54
Post #4





Group: Developer
Posts: 1318
Joined: 20-March 04
From: Göttingen (DE)
Member No.: 12875



QUOTE (kode54 @ Jun 16 2005, 06:28 PM)
  • 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".
*


heheh smile.gif
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
Go to the top of the page
+Quote Post
kode54
post Jun 23 2005, 15:41
Post #5





Group: Admin
Posts: 4623
Joined: 15-December 02
Member No.: 4082



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. biggrin.gif)
Go to the top of the page
+Quote Post
SebastianG
post Jul 9 2005, 03:44
Post #6





Group: Developer
Posts: 1318
Joined: 20-March 04
From: Göttingen (DE)
Member No.: 12875



QUOTE (kode54 @ Jun 16 2005, 06:28 PM)
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".
*


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 !!! biggrin.gif

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 this thread. (Post #5 is about a hack to make it work with Foobar 0.8.3)

Sebi

This post has been edited by SebastianG: Jul 21 2005, 11:44
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 20th October 2014 - 23:51