linuxaudio.org

--0016e649bb5cabd1f804790ef38a

Content-Type: text/plain; charset=ISO-8859-1
2009/11/24 Ken Restivo 
> On Fri, Nov 20, 2009 at 03:24:58PM +0000, Gwenhwyfaer wrote:

quoted text
> > On 20/11/2009, hollunder@gmx.at  wrote:

> > >> Is it a variable-rate MP3, by any chance? In which case, it's probably

> > >> dividing the length of the song in bytes by the bitrate of the first

> > >> frame; no really good way to fix that, other than by recording the

> > >> real song length (or mean bitrate) somewhere else.

> > >

> > > I'm sure there is a good way to fix that, just few players implement

> > > it. I'm sure the length can be found in some header or tag or

> > > something. Foobar2k manages to show it correctly, so should others.

> >

> > Well, there is one way to fix it - read the entire MP3 file at once

> > (since you only really care about the length of a file which you

> > already have all of) and counting each frame, without looking at the

> > bitrate. But for players which treat files and streams identically, I

> > guess an iffy time display is quite a way down on the list of sins.

> >

> > Mind, there's no excuse whatsoever for my portable MP3 player getting

> > it wrong. ;-)

>

> If I chop up an MP3 or Ogg file, using mpgsplt or oggz-chop, the time is

> forever wrong on that file. It'll show the start time that it was in the

> ORIGINAL file, not in this new, shorter file, which should start from 00:00.

> And, alas, my Sanza Fuze loses control of its bladder when it sees a file

> starting at 49:32, for example, and refuses to play it.

>

> -ken

Are we looking at a library (low-level) fault here? If so we should staple

and bug a bug report.
--0016e649bb5cabd1f804790ef38a

Content-Type: text/html; charset=ISO-8859-1

Content-Transfer-Encoding: quoted-printable
2009/11/24 Ken Restivo <ken@restivo.org>
On Fri, Nov 20, 2009 at 03:24:58PM +0000, Gwenhwyfaer wro=

te:

quoted text
> On 20/11/2009, hollunder@gmx.at <hollunder@gmx.at> wrote:

> >> Is it a variable-rate MP3, by any chance? In which case, it&#=

39;s probably

quoted text
> >> dividing the length of the song in bytes by the bitrate of th=

e first

quoted text
> >> frame; no really good way to fix that, other than by recordin=

g the

quoted text
> >> real song length (or mean bitrate) somewhere else.

> >

> > I'm sure there is a good way to fix that, just few players im=

plement

quoted text
> > it. I'm sure the length can be found in some header or tag or=

> > something. Foobar2k manages to show it correctly, so should other=

s.

quoted text
>

> Well, there is one way to fix it - read the entire MP3 file at once

> (since you only really care about the length of a file which you

> already have all of) and counting each frame, without looking at the

> bitrate. But for players which treat files and streams identically, I<=

br>

quoted text
> guess an iffy time display is quite a way down on the list of sins.

>

> Mind, there's no excuse whatsoever for my portable MP3 player gett=

ing

quoted text
> it wrong. ;-)

If I chop up an MP3 or Ogg file, using mpgsplt or oggz-chop, the time=

 is forever wrong on that file. It'll show the start time that it was i=

n the ORIGINAL file, not in this new, shorter file, which should start from=

 00:00. And, alas, my Sanza Fuze loses control of its bladder when it sees =

a file starting at 49:32, for example, and refuses to play it.
-kenAre we looking at a library (lo=

w-level) fault here? If so we should staple and bug a bug report.
--0016e649bb5cabd1f804790ef38a--