>
> Scott wrote:
> >> I dont' see why it shouldnt work - you don't need to decode, just unpack the
>frame and then repack it.
>
> then Mark wrote:
> >Easiest solution (but it wont shrink your files): go into each frame and replace
>the 12 bit "part2_3_length" field for channel 1 (both granules) with 0.
>
> Okay, but I understand that I'll need to decode each frame using some
> sort of huffman decompression. Where would I get this from, & what's
> the chance that this data will need more space than is available once
> altered & repacked? I'll also need the compression so I can rewrite
> the frames... At MP3Tech.org, it mentions about the format of the
> frame header, but nothing of the actual audio data- before, or after
> packing. As for shrinking the files, it doesn't matter, because
> bitrates like 56 & 128kBit/sec aren't much; I just thought it would be
> necessary to do once the side channel information had been deleted in
> M/S frames. Would it be wise to leave space for a VBR header frame on
> the off chance that the output stream requires more/less space?
>
It should be easier that that:
an MP3 frame can be divided into 4 parts:
1. syncword + header 4 bytes
2. "side information" Fixed size, but size depends on MPEG1/MPEG2 and
number of channels
3. scalefactors
4. Huffman encoded MDCT data.
All you have to do is zero out a few fields in the side information
(part #2 above) for the side channel. You wont have to do any huffman
encoding/decdoing, and nothing will actually change size.
My original idea of setting part2_3_length=0 for the side
channel will not work. But something that should work would
be to change the 8 bit "global_gain" to 0 for the side channel.
Several of the docs on MP3Tech give the exact decomposition
of the side information and from that you can figure out
exactly where "global_gain" is stored for each channel and
each granule.
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
