<kick>

On Sat, 12 Mar 2005 13:04:57 +0100, Karel Tromp <[EMAIL PROTECTED]> wrote:
> As an proud owner of the SB1: would it be difficult to implement it on
> the SB1 or solve it in Slimserver?
> 
> Karel
> 
> 
> On Fri, 11 Mar 2005 07:27:51 -0800, Vidur Apparao <[EMAIL PROTECTED]> wrote:
> >
> > It seems like the LAME INFO tag (described at
> > http://gabriel.mp3-tech.org/mp3infotag.html) does include the number of
> > padding samples. Bugs 1026 and 838 (they should probably be DUPed) cover
> > this issue. I think it's a fixable problem for Squeezebox2...possibly
> > not for initial launch, but shortly thereafter.
> >
> > --Vidur
> >
> > Familie Tromp wrote:
> >
> > > Hello Phil,
> > >
> > > Information about amount of frames etc. is found on the following
> > > site. It says too that frames are added at the end AND the beginning
> > > of each mp3 file.
> > >
> > > http://lame.sourceforge.net/tech-FAQ.txt
> > >
> > >
> > > "3.  Why does LAME add silence to the end of each song?
> > >
> > > Extra padding at the end of a file can be caused by a couple of things:
> > >
> > > 1.  Because the MDCT's are overlapped, it looks something like this:
> > >
> > > <--576 MDCT coefficients--><--576 MDCT coefficients--><--576 MDCT
> > > coefficients-->
> > >             <-- 576 samples PCM output --><-- 576 samples PCM output -->
> > >
> > >    So no matter where you truncate your MP3 file, the last 288 samples of
> > >    that granule will not be decoded.  So LAME appends 288 samples of
> > >    padding to the input file to guarantee all input samples will be
> > >    decoded.
> > >
> > >
> > > 2. If the number of samples is not an exact multiple of 1152,
> > >    then last frame of data is padded with 0's so that it has 1152
> > > samples.
> > >
> > >
> > > Before lame3.56, we just added a few extra frames to make sure all
> > > internal buffers would be flushed.  In lame3.56, we tried to pad
> > > with the exact minimum number of samples needed.  And in lame3.80,
> > > we finally fixed the bitstream flushing so that the final mp3
> > > frame is properly padded with ancillary data.  "
> > >
> > >
> > > Regards,
> > >
> > > Karel Tromp
> > >
> > >
> > > <reaction Phil Karn>
> > > Ah, I see. And I take it there's no field in the header that tells you
> > > how many audio samples are *really* in the track? If you had that, then
> > > you could just pad out the data during encode, and discard extra samples
> > > during decode.
> > >
> > > What is the size quanta, i.e., how much padding can be needed, worst
> > > case?
> > > _______________________________________________
> > > Discuss mailing list
> > > [email protected]
> > > http://lists.slimdevices.com/lists/listinfo/discuss
> >
> > _______________________________________________
> > Discuss mailing list
> > [email protected]
> > http://lists.slimdevices.com/lists/listinfo/discuss
> >
>
_______________________________________________
Discuss mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/discuss

Reply via email to