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.
Spring cleaning
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_skip
max_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_data
skip_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.