> From: [EMAIL PROTECTED] (Cem Alacayir)
> Date: Sun, 9 Jan 2000 02:00:16 +0200
>
> >this doesn't require you
> >to know anything about the structure of MP3 files: simply treat them as
> >binary data and join them together.
>
> but I think I should cut it carefully, I wouldn't want to cut at the middle
> of a frame (then there would be blanks)
> so it should be cut at the nearest frame-end point
>
> I want every part to be meaningful(continuous)
>
No need to bother trying to cut exactly on a frame boundary: since to
decode a given frame, you need some information from the previous
frame. Here is something from an FAQ i've been putting together
but not yet posted:
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.
The next problem is the overlapping frames. MP3 stores MDCT
coefficients which represent 1152 samples, but they are overlapped
by 50%. So for example:
frame N represents: 0-1152
frame N+1 576-1727
frame N+2 1152-2304
You need to add all the data together to complete the frame. The
complete frame of samples 576-1727 needs frame N, N+1 and N+2.
However, if you 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.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
