Hi! Gene Williams wrote:
I'm using the "part2_3_length" info to count bits, and I'm putting no filler between granules, which I think you confirmed is the correct way to rebuild the frame. Thank you so much for that - that may greatly narrow the scope of my debugging! Just to confirm, are you saying the first bit of a frame's "main_data" is the only one that's guaranteed to start on a byte boundary, regardless of the number of channels?
That is correct.
As for the output bitrate, to keep things simple for now, I'm forming what I'm calling "clean frames" with a variable bitrate. The parts of each input frame are organized using a class, separating pieces of the side-info and concatenating the bits of each granule of main_data into single bitsets. The new side-info frames are then formed with main_data_begin equal to zero, and the bitrate of each frame is determined based on the size of the main_data. After the main_data bits are laid down, zero bits are used to fill the required byte-count of that frame's bitrate. (After I achieve zero signal loss in the output, I'll get rid of this inefficiency and start using main_data offsets again.) Before I had the headers falling into place correctly, my mp3 player would not recognize the output as an mp3. I think this variable bitrate method is working, because now the mp3 player has no problem playing the output. Please let me know if it sounds like I may be overlooking something.
This should be ok. variable bitrate is supported by allmost all players.
Are these `filler` zero-bits what is known as "ancillary data"?
Thats exactly what it is. Yours Martin Ruckert _______________________________________________ mp3encoder mailing list [email protected] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
