On Fri, Nov 20, 2009 at 03:24:58PM +0000,
Gwenhwyfaer wrote:
On 20/11/2009, hollunder(a)gmx.at
<hollunder(a)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(a)lists.linuxaudio.org