Re: lmc bugginess

Robert Hart wrote:
> On Sat, 2003-03-22 at 22:09, Ed Sweetman wrote:
> 
> 
>>I'm making some compromises for speed, since ogg vorbis files dont have 
>>anything like xing's vbr tag which gives an exact abr and allows for 
>>exact time length without parsing the entire file and somewhat exact 
>>seeking (it would be pretty complicated to do exact seeking in a vbr 
>>file), i'm using the bitrate_nominal data.  the accuracy of this number 
>>is soley up to the encoder.   I could get the exact data but this would 
>>require 1 pass of the entire file which for files up to 6MB/10MB or so 
>>is less than a second on my system, but i also have an extremely fast 
>>hdd and nothing else is trying to get at it while i'm doing this.  The 
>>innacuracy shouldn't be too far off so long as the encoder isn't 
>>dropping the ball on it.  I believe we have the same problems for mp3 
>>files without the xing vbr tag that are vbr as well.
> 
> 
> If we don't get the exact time when a file is first scanned, will the
> database be updated when the track is actually played? I guess it
> doesn't do this right now. Maybe the method needs to be a preference? I
> think for some people getting reasonably accurate times could be
> important. (e.g. when putting togethor compilations, or planning a radio
> show?)

when a file "scanned" ie.  when you load it up, the playlist calls for 
the lmc to init it's decoder but that's it, if init is successful then 
the file is of that type of codec, so we use the respective metadata 
methods to retrieve the metadata.  time is however, not metadata in the 
file.  Time is a product of file size / average bitrate. In VBR this is 
troublesome because to get the average bitrate you either need a header 
that tells us explicitly and accurately or you have to scan the entire 
file.  mp3s that use the xing header have this capability, those 
encoders that do not use the xing header are SOL. OGG files are in the 
SOL catagory as even the bitrate_nominal variable is a rough estimate of 
the exact average.  So the database already only has access to the xing 
header in the mp3 case or an average based on the first data header 
(which is usually very far away from the actual average bitrate) or 
bitrate_nominal flag in oggs. Only the xing header in mp3s allows for 
accurate time measurement in VBR files.  It does not scan the entire 
file (except in the current ogg decoder it does because of the method we 
open the file)  Scanning a file on a modern system is extremely fast, on 
the order of less than a second for files upwards of 10MB, but this is 
not the case if you're actually doing something at the time or using a 
slow processor.

The guessing of the total time is important, but that's not where 
concern lays.  Our input subsystem knows nothing of the codec the file 
is in. So when our decode subsystem asks to seek in the file, you want 
to seek via time but time is a product of the decoded data, something 
the input subsystem has no way of using.  The decode subsystem has to 
ask the input subsystem to seek via byte offset of the file so our 
decode subsystem has to translate the time % you moved your slider from 
start of file into a byte value of the start of the encoded file.  This 
I'm fairly sure is not done, as our decode subsystem bypasses the input 
subsystem.  I'm not even sure the decode subsystems use the input 
subsystem for basically any of the basic functions it should be being 
used for.

in other words, without completely decoding the current file and seeking 
  on the pcm data and measuring time based on sample size and samples vs 
total size we cant give a 100% accurate seek model. And we'd have to at 
least read all the headers in a file to give a 100% accurate time length 
value.

Best guesses based on a little bit of data is usually correct with only 
a few cases of it not being but the advantages of using a estimated 
guess usually far outweighs the advantages of 100% accuracy for most 
people's uses, especially when you're gonna be putting that to a few 
thousand files.


> Although we all know that time is an illusion! right? Speaking of which,
> I make it lunch time. ;-)
> 
> I've noticed that there can be some quite dubious time estimates made by
> various programs. Especially if the mp3's are downloaded of the net.
> There seems to be some seriously broken mp3 encoders out there.
> 
> I have tracks that xmms gets a bit rate of 8kbps, (although when it
> actually plays it's 128kbps), and mpg123 -t shows as 448 kbps, and it
> skips most of the file as junk.
> 
> Maybe we need some kind of tool in the music browser to help you find
> and fix broken files.
> 
> Rob
> 




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf