2009/11/24 Ken Restivo <span dir="ltr"><<a href="mailto:ken@restivo.org">ken@restivo.org</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Fri, Nov 20, 2009 at 03:24:58PM +0000, Gwenhwyfaer wrote:<br>
> On 20/11/2009, <a href="mailto:hollunder@gmx.at">hollunder@gmx.at</a> <<a href="mailto:hollunder@gmx.at">hollunder@gmx.at</a>> wrote:<br>
> >> Is it a variable-rate MP3, by any chance? In which case, it's probably<br>
> >> dividing the length of the song in bytes by the bitrate of the first<br>
> >> frame; no really good way to fix that, other than by recording the<br>
> >> real song length (or mean bitrate) somewhere else.<br>
> ><br>
> > I'm sure there is a good way to fix that, just few players implement<br>
> > it. I'm sure the length can be found in some header or tag or<br>
> > something. Foobar2k manages to show it correctly, so should others.<br>
><br>
> Well, there is one way to fix it - read the entire MP3 file at once<br>
> (since you only really care about the length of a file which you<br>
> already have all of) and counting each frame, without looking at the<br>
> bitrate. But for players which treat files and streams identically, I<br>
> guess an iffy time display is quite a way down on the list of sins.<br>
><br>
> Mind, there's no excuse whatsoever for my portable MP3 player getting<br>
> it wrong. ;-)<br>
<br>
</div>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.<br>
<font color="#888888"><br>
-ken</font></blockquote><div><br></div><div>Are we looking at a library (low-level) fault here? If so we should staple and bug a bug report.</div></div>