Help: I need a proper method to detect 99% of all mp3 files
pynm0001 at comcast.net
Thu Jul 8 23:19:03 BST 2004
-----BEGIN PGP SIGNED MESSAGE-----
On Thursday 08 July 2004 08:34, Matthias Welwarsky wrote:
> Hm? mp3 frames are typically around 400 byte long, and decoding a few of
> them is probably much less a hassle than parsing a tag. So the "disk speed"
> not an issue, not even over network or USB.
Indeed it would still be an issue, at least for hard disks. Even the minimal
time needed to read the frames from disk would be more time than it takes to
decode the frames. And if you have more than one MP3 file you need to read,
the disk head is once again moving around like crazy.
Re-reading Scott's e-mail, I don't see where he says you should read the ID3
tag, as that would ALSO involve a lot of disk access. He's just pointing out
that you're pretty much IO-bound when checking whether files are MP3 files.
> Reading an ID3v1 Tag at the end of a file takes more time due to the
> necessity to seek.
Well a sane OS wouldn't actually move the disk head because a seek is issued,
it would wait until the next read. And even after the read is issued, most
OSes that I know of re-order the reads as appropriate to get decent
throughput. Since the size of the file is part of its inode information
(which we can assume has already been read, either by the program or in the
kernel cache after opening), it's not hard to seek to the end of the file
(which simply adjusts a kernel offset).
However, it still doesn't change the fact that it will be slow since it
involves the hard drive, as the CPU complexity is not very high.
- Michael Pyne
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the kde-multimedia