#13 Fix the bit-Reservoir at split points

[Anonymous]

Are there any plans to fix the MP3 bit-reservoir after
splitting?

Background: in general the second and subsequent file
will have invalid back references to main_data segments
in the previous file. This creates clicks at the
beginning of these files with some players. Other
players make the first few frames always silent
(because of this I guess).

With some constraints this problem can be fixed either
by prepending frames or by modifying the bitrates of
the first few frames (VBR only).

However, this requires to go one level deeper in the
MP3 structures. Once this is implemented it is straight
forward to implement lossless CBR->VBR conversions, and
the other way around with restrictions, too.

I planned to implement this in my own MP3-tool
(frameanalyzer), but I did not find the time so far. At
least I do not want this to be done twice. I also may
contribute to this subject. Only time is the limiting
factor.

Marcel Müller
(mueller at maazl de)

[Matteo Trotta]

Logged In: YES
user_id=557210

Yes, I know the problem of bit-reservoir and
I planned to try to fix this problem, but in this moment
I can't find the time to work on mp3splt, too.

If you'll start to work on this (you are absolutely welcome!
;-),
please let me know. And me too, I'll do the same with you.

Thank you very much for your interest in mp3splt.

Matteo

[OrJ]

Logged In: YES
user_id=33864

Hi,

I am too ignorant of mp3 internals to follow you here, but I noticed
splitting a file in 2 with mp3splt, and listening to these 2 segments in a
row with mpg123 indeed leaves a blank of typically 0.5 to 1 second.

I also noticed that the info is not lost, since wrapping back the 2
segments gives a single file where no hole is heard. By the way, would
this still be true if you fix the empty-bit-bucket problem you mentioned?

I noticed these things using a dumb script I made to help manually
adjusting the split point, by looping a split/play/keyboard_adjust
sequence. It would be great to have some some GUI helping in there, but
there is no point in fine-tuning the split position if half a second is lost
anyway!..

Just thought I should write to try and motivate you expert guys, as there
really is a need for a good cut-without-decoding tool (reencoding is so
damned slow!). Except for this little problem, mp3splt is perfect! Thanks
anyway for the superb work already done!

JO

[Nobody/Anonymous]

Logged In: NO

Is there any news on when this feature might be implemented?
I have been looking for something to perform this task for ages!

[Munteanu Alexandru]

Hello,

I've read some docs about the mp3 frame header & bit-reservoir, as I'm trying to find solutions to this problem.

As far as I've read, a playable "data frame" includes several frames. Each frame has a back reference to the first frame where the "data frame" starts. So, if we split in the middle of a "data frame", which is mostly the case, we will have a similar scenario :
* suppose we split at the frame number 5 from the following "data frame" containing 9 frames :
..., 1, 2, 3, 4, 5, 6, 7, 8, 9, ...
* we will have the end of the first split file :
..., 1, 2, 3, 4, 5
* and the start of the second split file :
6, 7, 8, 9, ...

Since frames 6, 7, 8 and 9 have negative offsets to the frame 1, which is the begin of the "data frame" and does not exists in the second split file, some players will produce a glitch when starting to play to audio data.

Here are some possible solutions in fixing the bit-reservoir issue :

1) append silent frame(s) before the frame number 6 in the previous example
2) remove frames 6, 7, 8 and 9
3) modify the frames 6, 7, 8 and 9 to act like they were a complete "data frame" 1, 2, 3 and 4 ( <=> change the "data frame" size)
- (seems like we can "poke around the frame" with libmad : http://mlblog.osdir.com/audio.mad.devel/2003-11/index.shtml)

Do you have any other solutions ?
What do you think is best ?
I believe that number 3 looks good.

--
Alex

[Munteanu Alexandru]

Finally, the "remove frames" is not good, because frame number 9 can have data for the following "data frame" (I think).

[Munteanu Alexandru]

A first experimental version is now available in the latest mp3splt release (2.6.2)