Efficiently Reading ID3v2 Tags Over HTTP?

Paul Crowley asks: "Given an HTTP URL for an MP3 file, what's the best way to read its ID3 tags on a GNU/Linux system? It shouldn't be necessary to fetch the whole file: HTTP byteranges should make it possible to fetch only the tiny fraction that's needed, for a big saving in network bandwidth. However, existing ID3v2 libraries are designed to read local files. Extending these libraries for this purpose, or implementing a new one, would be a big job. What's the clean solution - is FUSE the best way, or is there a simpler way that doesn't require root privs? Can I do it using the existing id3lib binary?"

Perhaps not this simple

[Anonymous Coward]

Why couldn't you save the result of the remote HTTP access to a temporary local file and allow the libraries access to that file?

You'd have to extend the API

[Ayanami Rei]

You'd better be prepared to extend the API with a URL handler...

There's no point adding http:// support without also adding ftp:// URL support. FTP supports range fetching as well.

So you have handlers for http:// URLs, ftp:// URLs, and file:// URLs.

Then you'd have to map all the old (compatibility) file-oriented APIs into the new function handlers for file://. (Or maybe the opposite, map file:// into the old API, leaving the old implementation intact)

Silly Question

[Anonymous Coward]

You know from the mp3 spec where the tag will be. Just snag that information and feed it to the preexisting library. If you have to, make a temporary file that meets the bear minimum definition of an mp3 (using the snagged tag info, of course).

Without looking and without knowing, I'm willing to bet there's a Perl module for processing mp3 ID3v2 tags. The whole project can probably be done in Perl in a very small amount of lines.

HTTP 499

[cryptor3]

It seems like it shouldn't be that hard. You just initiate the HTTP transfer and then cancel it as soon as you have as much data as you need.

I haven't actually done it, but speaking as a server operator, when I look through my server logs, you see some hits that end with status code 499, meaning that the transfer was aborted. So you just have the client software you're writing close the HTTP connection after it locates the end of the ID3 tag. It's probably not 100% efficient, but obviously a lot better than reading the whole MP3 file.

I'm assuming you're doing this in C/C++, but I'll try to do a prototype in perl.

Re:ID3v2 Sucks

[dave420]

It all made sense to me. You did understand the purpose of sync-safe bytes, right? They're not just there to piss people off.

I wrote a class for handling ID3v1/2 tags, and it works fine. I use it nearly every day, and it's processed nearly 5000 songs without fail (various versions of v2 tags, mixed in with the old classic v1), from Apples, *nixes and windows.

The format is so specific you can code for almost any eventuality. It's one of the easier binary formats I've worked with, and I think it's a great place for developers to learn about manipulating/creating binary files.