>
> Hello,
>
> In order to give that idea I had last month about an "album-header",
> in order to complete (imho) mp3 as a platform to encode all kinds of
> cds seamlessly, as opposed to only non-live/mix cds given current
> implementation, a chance, I'd like to get some information :) [yes, it
> is english]
>
> I looked at the source of lame concerning the xing VBR tag, and I get
> what's in the 140 bytes past "Xing".
>
> My questions:
>
> -what's in the header data, in order to get a good mp3
> frame, that plays .03secs of silence instead of garbage?
> (where do I look in the lame code for this?)
>
Just take a look at VbrTag.c. I assume the Xing VBR header
decodes to all 0's, and the VBR table of contents is
placed in the ancillary data region. But I've actually
never checked this.
This VBR tag/frame frame can be any valid bitrate, so if you want to include
extra information (like start and end padding to be removed) it
would be easy to go to a 80kbs frame to make room for this information.
The amount of ancillary data available for information:
frame_size - sideinfo_len - size_of_Xing_header
size_of_Xing_header = ? (look in VbrTag.c)
sideinfo_len is:
MPEG1 mono: 21 byts
MPEG1 stereo: 36 bytes
MPEG2 mono: 13 byts
MPEG2 stereo: 21 bytes
frame_size = frame_sample_size*bit_rate/sample_rate.
For MPEG1, frame_sample_size = 1152
For MPEG2, frame_sample_size = 576
>
> -How big would the maximum info content be in a 44.1 320kbit/s frame
> (so everythinig beside header I assume?, and 320being the largest
> possible mp3 frame?).
>
> -What about 48kHz and alikes (does this interfere with info-content)?
>
Kind of like turning CRC on and off, many players cant handle
samplerate changes from frame to frame, so you probably cant use
anything other than a 44.1 khz frame.
> -Imagine I define a record structure containing all info I need for my
> header thingy, would it be possible/adviseable to use that huffman
> code in order to get the text fields smaller? Pro's / Cons? (I'm
> thinking no because of the relative (as compared to filesize) small
> gain vs the increased complexity/no plaintext.)
>
I would say, only if you cant fit the data into a 320kbs frame.
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
