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