Python Audio Tools / News: Recent posts

2.7 released, at long last

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.

Posted by Brian Langenberger 2008-02-09

Python and the Evolution of Python Audio Tools

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

Posted by Brian Langenberger 2007-12-05

FLAC vulnerabilities and the Python Audio Tools

eEye Digital Security has issued a report listing 14 vulnerabilities in the libFLAC implementation. See

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

Posted by Brian Langenberger 2007-11-20

PulseAudio support added

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.

Posted by Brian Langenberger 2007-11-10

ReplayGain support improved

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

Posted by Brian Langenberger 2007-11-03

libcdio 0.79 released

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.

Posted by Brian Langenberger 2007-10-27

PCM conversion work-in-progress

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

Posted by Brian Langenberger 2007-10-09

oddball RIFF WAVE chunks now supported

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.

Posted by Brian Langenberger 2007-09-28

.flac, .mpc and .ape overhauls

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

Posted by Brian Langenberger 2007-09-25

metaflac's return

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.

Posted by Brian Langenberger 2007-09-18

metaflac requirement eliminated

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.

Posted by Brian Langenberger 2007-09-17

bugs, fixes and other improvements

It seems track2xmcd(1) was also broken by the Great Split, though fixing it is a simple matter of adding ",DummyAudioFile" to'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

Posted by Brian Langenberger 2007-09-14

fixes pending for 2.3

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.

Posted by Brian Langenberger 2007-09-12

Future Python

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.

Posted by Brian Langenberger 2007-09-06

Ogg FLAC support added

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

Posted by Brian Langenberger 2007-09-04

Python 2.4.4 build fix

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.

Posted by Brian Langenberger 2007-08-24

Yet more MetaData improvements

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

Posted by Brian Langenberger 2007-08-23

Python Audio Tools 2.2 released

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

Posted by Brian Langenberger 2007-08-17

Metadata revamp in progress

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

Posted by Brian Langenberger 2007-08-13

Python Audio Tools 2.1 released

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

Posted by Brian Langenberger 2007-08-02

Python-based FLAC decoder functioning

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

Posted by Brian Langenberger 2007-07-28

final 2.0 released

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.

Posted by Brian Langenberger 2007-07-21

final 2.0 version imminent

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.

Posted by Brian Langenberger 2007-07-19