linuxaudio.org

--00151773e6ba512eb50479108fc6

Content-Type: text/plain; charset=ISO-8859-1
I've noticed that these time issues are the problems with Songbird choking

on my FLAC files as well.  If a song is listed as being 15 days, 6 hours and

50 minutes long, we got problems.......
I haven't dug too far into it but I'm thinking that it's an issue with how

the song gets tagged??
-aaron
On Mon, Nov 23, 2009 at 11:36 AM, Ray Rashif  wrote:
> 2009/11/24 Ken Restivo

quoted text
>

>> On Fri, Nov 20, 2009 at 03:24:58PM +0000, Gwenhwyfaer wrote:

>> > 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.

>

> _______________________________________________

> Linux-audio-user mailing list

> Linux-audio-user@lists.linuxaudio.org

> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

>

>

--00151773e6ba512eb50479108fc6

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

Content-Transfer-Encoding: quoted-printable
I've noticed that these time issues are the problems with Songbird chok=

ing on my FLAC files as well.=A0 If a song is listed as being 15 days, 6 ho=

urs and 50 minutes long, we got problems.......I haven't dug to=

o far into it but I'm thinking that it's an issue with how the song=

 gets tagged??

-aaronOn Mon, Nov 23, 2009 at 11:36 =

AM, Ray Rashif <schivmeister@gmail.com> wrote:

2009/11/24 Ken Restivo <ken@restivo.org>
On Fri, Nov 20, 2009 at 03:24:58PM +0000, Gwenhwyfaer wrote:

quoted text
> On 20/11/2009, h=

ollunder@gmx.at <hollunder@gmx.at> wrote:

quoted text
> >> 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 libra=

ry (low-level) fault here? If so we should staple and bug a bug report.

_______________________________________________

Linux-audio-user mailing list

Linux-audio-user@l=

ists.linuxaudio.org

http://lists.linuxaudio.org/mailman/listinfo/linux-audio-u=

ser
--00151773e6ba512eb50479108fc6--