Dear Dr. Ruckert, Thank you for your reply! 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?
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. Are these `filler` zero-bits what is known as "ancillary data"? Thank you so much, Gene -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ruckert Martin Sent: Wednesday, May 25, 2005 2:45 AM To: MP3 encoders development list Subject: Re: [mp3encoder] mp3 bit re-arranging Dear Gene, this looks ok to me. The only potential problem I do see is the merging of the two main data sections because of the ancillary bit. After the second granule in both channels there might be ancillary bit. If you concatenate the data there must be no ancillary data in between the data blocks. So you must determine and remove these bits. It is simple to determine the exact location and size of the main data based on the side information. But then you need a bitwise concatenation. While the main data of the second channel will start on a byte boundary it may or may not do so when inserted in the combined stream. You may not change the size information (main_data_bits) in the side information, because this is used to determine the end of the small values section in the huffman decoder. An other problem (you dont say much about it) is the determination of the new header, which must take into account the new bitrate (which is about halve of the original bitrate but not quite. The amount of data per frame almoust doubles but the number of samples per frame stays constant. With the new bitrate again you have a new frame size and may need more or less ancillary bit. If that isnt the problem, I guess its a case for intense debugging. Yours Martin Ruckert Prof.Dr.Martin Ruckert Munich University of Applied Sciences FB07 Mathematics and Computer Science Lothstrasse 34 D-80335 Munich GERMANY Gene Williams wrote: > Hi! > > I'm trying to programmatically take 2 mono mp3 file inputs, and output > a stereo mp3 file with 1 input on ch0 and the other input on ch1 - > without decoding and re-encoding. I'm using ISO 11172-3 for > reference, thought I understood the bit organization, and I've put > together some code that creates the output I wanted it to, but the > audio's integrity is not maintained. It seems like I've very close, > because the peaks and valleys of each channel of the output seem to > match the peaks and valleys of their corresponding input, but the > audio is garbled. I think bits are slightly skewed > > I'm arranging the output's side-info like this: > - the proper header > - main_data_begin > - private_bits (3) > - scfsi from input 1 > - scfsi from input 2 > - the 59 bits of the remaining side-info for input 1's gr0 > - the 59 bits of the remaining side-info for input 2's gr0 > - the 59 bits of the remaining side-info for input 1's gr1 > - the 59 bits of the remaining side-info for input 2's gr1 > > and the output's main data like this: > - input 1's gr0 main data according to its corresponding part2_3_len > - input 2's gr0 main data according to its corresponding part2_3_len > - input 1's gr1 main data according to its corresponding part2_3_len > - input 2's gr1 main data according to its corresponding part2_3_len _______________________________________________ mp3encoder mailing list [email protected] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
