Python Audio Tools / News: Recent posts

Version 2.7 has taken quite awhile to get out the door, I'll admit. Despite the few feature enhancements between this and 2.6, I finally got sick of all the little bugfixes piling up and decided to release it.

I'll try to get my Git repository hosted somewhere in the near future so people can get fixes or new features a bit faster if they'd like.

As I've transitioned Python Audio Tools from working primarily with audio metadata (track tags, playback parameters, etc.) to handling audio data itself (FLAC decoding, track resampling, etc.) I've come to better understand what Python is good at, and what it still struggles with.

Python is very good at reading in chunks of data, binary or otherwise, parsing them and doing some work with them. It's proven to be fast, reliable and maintainable.... read more

eEye Digital Security has issued a report listing 14 vulnerabilities in the libFLAC implementation. See http://research.eeye.com/html/advisories/published/AD20071115.html

Since Python Audio Tools uses many of its own routines to handle FLAC and its metadata, I've taken a close look at this report to ensure I haven't missed any vital errors. Fortunately, due to Python's design, the bulk of them simply do not happen barring any bugs in the Python interpreter and I shall explain why.... read more

I've extended trackplay to support both OSS and PulseAudio as output methods - PulseAudio being the default if present. There's many advantages to this. First, trackplay doesn't hog /dev/dsp and block all audio on the system. Second, PulseAudio supports 32-bit floating point samples, so I don't have to dither high-definition audio anymore. This saves a lot of CPU during playback.

Assuming I don't stumble across anymore bugs, PulseAudio and ReplayGain will be the focus of a 2.6 release.

I've been really picky about adding proper ReplayGain metadata during track creation/conversion, right from the first versions of Python Audio Tools. The trouble is, I've never actually done anything with it.

But thanks to all the infrastructure work I did for PCM conversion, I've been able to build a ReplayGainReader wrapper for PCMReaders (similar to the PCMConverter wrapper) and basic ReplayGain support for trackplay(1) literally came together in about half an hour.... read more

If you've had any difficulty extracting audio from difficult CDs, it might be worthwhile to upgrade to libcdio 0.79 which features numerous bugfixes. I've encountered no errors using it with Python Audio Tools and should be a worthwhile upgrade.

High-definition, multi-channel audio is one of those features Python Audio Tools supports, but I'm pretty sure isn't widely used. Right now, a lot of the lossy codecs will choke on PCM streams with lots of channels and bits and big sample rates. I've already got channel culling and bits-per-sample scaling working well enough, but resampling will be another story.

I could use a high quality external resampling library and make hi-def audio ubiquitous throughout the tools. But when most people are only interested in CD-quality, that's the very definition of an obscure dependency.... read more

Most of the time, .wav files are thin wrappers around a big blob of PCM data. However, it's possible to stick non-PCM chunks in .wav files and not break anything. Some fancy audio editing tools have been known to do this, for example. But since Python Audio Tools previously routed all audio through PCM streams, those chunks would get lost during any conversion.

That's not entirely lossless.

Therefore, I've short-circuited the conversion to/from RIFF WAVE files to ensure those chunks are kept by the formats that support them - namely FLAC 1.2.1, WavPack and RIFF WAVE.

There's been a few developments in the world of audio formats, some of which will need a bit of coding on my part to support.

Rumors of an update to the FLAC format have been floating around for awhile. Turns out it's a minor update to the partitioned Rice which won't be difficult to support. I'll be updating my FLAC decoder and documentation once I can test out the changes on real files.

Musepack Stream Version 8 is also in beta testing. I'll need to update my documentation and Musepack recognition code for that, too. Hopefully it'll have some portable tools this time around, too. I've never gotten mppdec to work on PPC and I hate leaving formats untested on big-endian machines.... read more

I'm in the final testing phase for Python Audio Tools 2.4 and just now noticed that FLAC files created via streaming PCM data have no SEEKTABLE metadata blocks. This doesn't appear to be a big deal since players like "xmms" have no trouble seeking through FLAC files without SEEKTABLEs, but I would like to have them added at create-time. Therefore I'm bringing back the "metaflac" binary requirement. I don't expect this will cause any inconvenience since you'll want "metaflac" around anyway for ReplayGain support.

Though I'd hoped to have the new version up today, I'd like to do a bit more testing to the new features before calling it final. So, I'd estimate 2.4 will be up Wednesday.

The latest change is that the "metaflac" binary requirement has been removed and replaced with a Python implementation. This is because the new images handling routines require metaflac to understand PICTURE blocks, but PICTURE blocks are a relatively new addition to FLAC. So I could either require everyone to download the latest FLAC, or I could add PICTURE support myself. I've chosen the latter in the hopes of saving everyone some problems.

It seems track2xmcd(1) was also broken by the Great Split, though fixing it is a simple matter of adding ",DummyAudioFile" to __freedb__.py's "import" statement. APEv2 tags were also broken when values contained binary data, and ID3CommentPairs had some attribute setting/fetching bugs. Basically a whole pile of little things that I'm hesitant to build a whole 2.3.2 release out of; I'd rather go directly to 2.4 and bring out some real improvements by Monday or thereabouts.... read more

I screwed up a few things when getting the 2.3 release out the door. tracktag(1) falls over when trying to re-tag mp3 files which contain non-text frames (like APIC) and the table of contents in the formats reference is messed up.

Though these problems are fixed in the development version, I'll backport my fixes and have a 2.3.1 release up shortly.

Though I'm a bit slow, I've noticed the first Python 3.0 alpha is out. This isn't going to be compatible with Python Audio Tools whatsoever, at least in the short term. Not to mention I haven't fully transitioned to requiring Python 2.5 yet. However, I will be keeping an eye on language changes and I'll try to have my own code converted as soon as it's feasible.

In the spirit of not requiring obscure dependencies, I'll maintain a 2.x compatible fork of Python Audio Tools until 3.x becomes more widespread and installed by default. Backporting's going to be a pain, but I expect my own development will have slowed down by then.

Though I'd spent a good deal of time wrestling with the poorly documented Apple Lossless format, I decided to take a break and finally get Ogg FLAC working. Although the 'flac' binary does a great job of encoding and decoding them, there simply isn't an existing tool to edit Ogg FLAC metadata. So, I adapted my routines to set Ogg Speex metadata to Ogg FLAC and now everything is working properly except for ReplayGain (which I'll need to calculate by hand).... read more

The bitstream.c module wasn't building correctly due to missing Py_ssize_t which wasn't introduced until Python 2.5. I've released a new version with this problem fixed. Python 2.5 users don't need to upgrade since nothing else has changed.

I had planned to put the "plumbing" on hold while I added more formats, but the temptation to make tracks manually taggable proved too strong. I wanted to throw together a quick tracktag(1) executable based on the existing get/set_metadata() routines.

The trouble is, setting from "least common denominator" metadata is a lossy process since generic MetaData objects won't necessarily have everything from the original track. What I wanted to do was only update what's been changed and leave the rest of the metadata alone.... read more

2.2 is out the door, now with a better metadata handling system and improved file detection routines. The get_metadata() and set_metadata() routines were simply getting too complex so they've now been simplified and the burden of metadata conversion has been shifted to the metadata formats themselves.

In addition, track detection is much improved. Instead of taking a small chunk from the file header, the is_type() routines now get a seekable file handle to work with and can bounce all over the file if need be.... read more

The original baseline MetaData object has been revamped with a few extra fields, most notably a separate "performer_name" to allow for cases when the original artist and performer differ.

I've also made all MetaData subclasses symmetrical. This means that re-encoding an MP3 to another MP3 will result in the new file having the exact same tags as the old. (That's never a good idea, of course, but it cleans up the code considerably).... read more

I've added a fully-functioning FLAC decoder in pure Python, along with documentation about its implementation. Find it in the audiotools.flac Python module. This decoder is for documentation purposes and is designed for simplicity and clarity rather than speed, so it will run significantly slower than the official FLAC decoder.

In addition, directories will now be made automatically as needed during the creation of new tracks.... read more

I've sacrificed a week's worth of spare time to build a functioning FLAC decoder in Python. Right now it's limited to 16-bit audio and it will never win any awards for speed. This implementation is a meant for documentation purposes. My hope is that by providing straightforward, commented Python code and a full writeup in the manual, people who are interested in the inner workings of the FLAC format will be able to understand it with minimal effort.... read more

Since no major issues came up during the beta release, I've made a final 2.0 release with a few minor updates. The Musepack format has been added (along with documentation) and a few bugs have been fixed. Still bits of cleanup to be done, but I don't want to have a beta sitting out for too long.

Since no one has contacted me with any bug reports or documentation corrections, I'm assuming no one's hit any show-stopping bugs or major problems. So, I'll have a final 2.0 version with a few minor bug fixes posted within the next day or two.