Help: I need a proper method to detect 99% of all mp3 files

[Michael Pyne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

Regards,
 - Michael Pyne
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA7chbqjQYp5Omm0oRAnDCAKCDUubJm+1bI89lREh43E7A43ellACfbAHI
IRpxAGj+Y9zi7iafPJghuTY=
=KE0L
-----END PGP SIGNATURE-----