I am curious as to how stupid spammers really are, so I have created two very special e-mail addresses, and broadcast their existence to the world. Now, I wonder, how long it will be before some spider finds its way to them, and I start getting offers of unbelivable riches and bodily improvements?
In this here entry I will rant a bit about some of the stupidity that ID3v2 tags seem to have forced upon the world. First, though, a primer on ID3 tags is probably in order.
ID3v1 tags have a fixed length and layout (i.e. fixed-length
records), and they are always tacked onto the end of MP3 files. This is
both a blessing and a curse. It is a blessing because ID3-aware
applications have a very easy way of getting at them, just seek to the
last 128 bytes of a MP3 file and see if the first three bytes there are
the string TAG. It is a curse because the fields are fixed
length (e.g. 30 bytes for the song title), so if you have a song title
that is longer than the length allowed its tail will be chopped off.
Naturally, this could not continue. And, ID3v2 tags where introduced. ID3v2 is a very different beast from ID3v1; an ID3v2 tag is variable length and consists of a number of variable length parts (e.g. song title). Again, this is both a blessing and a curse. Now, though, the reasons are reversed. It is a blessing that there is no practical limit to the length of for example song titles. But, with ID3v2 tags it is impossible to tack them onto the end of MP3 files, since you cannot know their length in advance (and so cannot find them by seeking to a fixed length from the end of MP3 files). So, ID3v2 tags are put at the beginning of MP3 files.
Now, we come to the problem. It seems that (at least) one MP3 encoder writes ID3v2 tags with a whole lot of trailing zero bytes. This is not a problem for most MP3 players, because they quietly skip over junk in MP3 files. Alas, it is a problem for me, since I would like to write simple and efficient Python code to parse MP3 files. Besides, leaving junk in my data files goes against my sense of aesthetics.
The reason for putting zero bytes after ID3v2 tags is not clear, but I do have a few theories. Currently, I lean towards the belif that the zero bytes are there so minor changes can be made to the tags without rewriting the entire MP3 file. It’s the closest I have to an explanation, there is just one problem with it: It is a dumb reason. Really, really dumb, even.
I decided to solve The Problem by side-stepping it. Instead of having only one MP3 parser I decided to have to different ones. One simple and efficient parser for good MP3 files. One (slightly less) simple and inefficient parser for bad MP3 files. The bad-MP3-file parser I only use for repairing MP3 files.
See my Python MP3 Tools for the MP3 parsers and the MP3-file repairing script.
When I showed mp3.py to the world it was without too
much forethought on my part, which has naturally come back to haunt me.
The problem is that mp3.py was originally part of another
project (Jukebox), and so
it did not have setup.py, unittests or anything of that
sort. That I have now decided to remedy by giving mp3.py
it’s own project: mp3
tools.
At the same time I also did some spring-cleaning in the code. This
means that mp3.frames no longer know the
max_skip or skip_data arguments.
max_skipmax_skip was needed for working around all the broken
MP3-files that exist in the wild, it controlled if
mp3.frames should be strict or lenient. Now, it is always
strict. This, of course, means that all the broken MP3-files out there
cannot be read with this library. Instead the new library comes with a
utility for fixing the broken MP3-files, repair-mp3 reads
MP3-files like your normal MP3-player (silently skipping over junk), and
rewrites them with only good the MP3-frames and ID3-tags intact.
skip_dataskip_data was added after Ned Batchelder
suggested that reading the MP3 frame data into core was overkill for his
m3utree utility. But,
mp3.frames is a generator, so it never reads more than one
frame into core at any time. Since most MP3 frames around 500 bytes long
the overhead is negligible.
I added the code because a few test-runs indicated a rather big speedup
when seek‘ing past the frame data. But, it seems I screwed
up the original benchmarks, because now I get a slight slowdown when
seek‘ing past frame data. Given that the code is causing a
slowdown and complicating mp3.frames, I have decided to cut it.
Today I have been doing some minor hacking on my blog.
I changed the visible timestamp on the rants from absolute to
relative; the absolute timestamp is now a title attribute
on the timestamp span (i.e. the asolute timestamp is shown
as a tooltip, if you hover your mouse over the relative timestamp). In
the same move I went from displaying the absolute timestamps in CET to GMT. This goes for all pages but the
archive, where absolute timestamps still rule supreme.
The code to calculate
and format the relative timestamps is naturally
available in my favourite computer dialect
(provided you don’t start foaming around the mouth when I mention the
GPL (speaking of which, have
I missed all the obvious jokes about the General Pubic License
(sic) being viral, or are they just less obvious than I think?!)).
Are You a Blogaholic? has this to say about me:
You are a casual weblogger. You only blog when you have nothing better to do, which is not very often. There’s nothing wrong with that. But if you’d post a little more often, you’d make your readers very happy.
Ok, I guess it’s time for some Real Content(tm) from my side, so I will try to write about things I have been up to lately. I will strive to keep my gaze high above my navel, and hopefully write something that someone out there might find interesting.
Yup. I got myself a Powerball. The producers of the Powerballs claim that they help alleviate CTS and RSI, and I am pretty sure I suffer from one of those. So, I am hoping playing with my new Powerball will actually help me, because hurting in the wrists and arms from too much computer work is no fun for me.
I will have to google a bit for information on how exactly this wonderful toy will help me, and what the best way to train my wrists for l33t-keyboard skillz is.
Oh.. Current RPM-record is 10,529.
Lately almost all my hacking non-sleeping hours
have been spent on the backend for this here blog, my private RSS
aggregator and the backend software I build these things on (Sheared and Entwine). Noteable features
I have recently implemented:
I think I squashed a rather annoying bug in Jukebox; the jukebox that I
start in local.start would shut down when XMMS
disconnected, so one would get a Could not connect
error message
when asking XMMS to start playing again.
The fix was to wrap the client-connection writing in a
try: except: break-block; which is really weird, because
exceptions are supposed to be caught higher up in the
call-stack. Something is rotten in the state of my
exception-handling code :-(.
Note to self: when running the jukebox undaemonized the offending exception is caught and logged, but it mysteriously goes astray when the jukebox is daemonized and the jukebox process shuts down. Maybe you/I should look at what’s up with exception logging when the jukebox is daemonized? Alas, not now. I have books to read, and my wrists hurt.
Not entirely sure I succeeded in staying away from navel-picking. Then again, I am still practicing my blogging manners.
Quote from some random girls personal:
playing with zen (my great dane).
doing something scandalous..
Que, imagined conversation:
<me> am I the only one finding that quote slightly disturbing?
<me> btw. don't ask how I found it; not browsing over-seas personals I assure you
<you> riiiight..
<you> you are single, right?
<me> yes :-(