| gabriel rosenkoetter on 27 Feb 2009 05:33:39 -0800 |
|
At 2009-02-26 19:16 -0500, Mark M. Hoffman <mhoffman@lightlink.com> wrote: > I'm willing to bet that the earlier versions simply fired off the encoding > thread as soon as the file was opened, and ran to completion whether or not it > was needed. So the 25 file hypothetical was a real problem. ;) It might be > even worse than that if the file is opened by two different processes: a dir > tree/tag viewer and then the decoder itself. > > Now, it looks like the fs will hold off on the encoding until it's actually > needed. Erm. If memory serves, id3[v2] information is stored at the *end* of an mp3 file, so unless you're pre-fetching or lying to the lseek(2) call, you would have to process the whole file first. My guess would be that they're doing the latter now, since you don't have to read all the way through a FLAC to get the metadata, I'm just not sure how they "know" that's what a caller is after. I should probably just go look at the code at this point, though. -- gabriel rosenkoetter gr@eclipsed.net Attachment:
pgpyKU0qtMpoC.pgp ___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
|
|