> Date: Thu, 27 Jan 2000 00:46:33 +0000
> From: Andre Pang <[EMAIL PROTECTED]>
>
> please excuse me for my ignorance of the mpeg format - is a frame a
> consistent size? i've had an on-the-side project to do a very basic
> distributed mp3 encoder which simply splits up the original .pcm file into
> smaller (eg: 30 second) chunks, runs a certain number of lame/mp3enc/etc
> processes on each chunk, and recombines them back into the final .mp3.
>
> if each mpeg frame is always a set number of samples (in the original
> .pcm), then it should be easy to do this process. while it's not completely
> efficient, i hopefully plan to make the chunk size arbitrary, so that you
> can split the file up into 30 second, 60 second, 5 second, etc. chunks,
> depending on how big your original file is and how many computers
> (processors) you have available. i don't even need an option in the mp3
> encoder to discard the encoded frames, because ideally this front-end will
> be intelligent enough to know about frames and manipulate the final stream
> from the encoder.
>
> but all this is possible only if each frame represents a consistent set
> of samples. from my limited knowledge, i am assuming that this _is_ the
> case, even with vbr.
>
> can somebody please verify this for me? :)
>
I actually spent a week or so working on this before I started
working on LAME. I was following up some of Mike Cheng's work.
Mike also claimed he was interested in parallel encoding, but
I assume the real application is seamless splices of 30s mp3s created
by the FhG demo encoder :-)
I concluded this was impossible in general, because of the
bitreservoir. (see below). But that was before VBR!
If you allow a VBR stream, I think it should be possible
to create seamless splices of independently created overlapping
sets of mp3 files.
I've modified this question from the FAQ:
==========================================================================
2. Why cant MP3 files be seamlessly spliced together?
There are several reasons this is *very* difficult:
The MP3 data for frame N is not stored in frame N, but can be spread
over several frames. In a typical case, the data for frame N will
have 20% of it stored in frame N-1 and 80% stored in frame N.
If the encoder builds up a large bitreservoir,
the data for frame N can actually be stored 4088 bits back in
the bitstream. Then if a very hard-to-encode passage comes up,
then the encoder is free to use the normal bits for this frame
plus up to 4088 more. The resulting data will then take up
several frames. The starting negative offset
in the bitstream for the data associated with a given frame in bytes is
given by main_data_begin.
Thus chopping a mp3 file on a frame boundary will almost always result
in the corruption of the data in that frame. mpg123 will report
such errors as "cant seek past beginning of file" or something
like that.
A propper cut-and-past job cound be done, but it would have to
seperate all the data from the frame headers, and then
replace the frame headers in the correct location in the new
stream. One problem: this may generate data for frame N that
is stored too far back, say 4100 bits back. In that case, the
main_data_begin field will be incorrect since it can be at most 4088.
Two possible solutions:
1. Create mp3's with the --nores option in LAME,
(disabling the bit reservoir and reducing quality somewhat),
these mp3 files can be simply cut and pasted on frame boundaries.
2. Use VBR and overlapping encodes. For example:
stream A = encode frames 0-99
stream B = encode frames 97-200
First remove the frames 97,98 and 99 from stream B. It is
important to use overlapping encoding because of the
psycho-acoustics. Then take frame 100 in stream B. Most of the
time, some data for frame 100 will be stored in frame 99. Take a
look at frame 99 from stream A. If there is enough space, take the
frame100 data which was stored in stream B/frame 99, and store it
in stream A/frame 99. If there is not enough space, replace frame
100 with a higher bitrate frame to make enough space.
Now stream A and stream B can be concatenated together.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
