-
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.
2008-02-09 15:24:52 UTC by tuffy
-
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.
Python is not very good at doing lots and lots of little calculations. ReplayGain playback only works because I can run it in its own thread, despite the simplicity of actually applying it. FLAC decoding, resampling and ReplayGain calculation are all embarassingly slow, despite the use of profiling and C extension modules to speed up the process.
Since software that's too slow isn't practical, I'm going to need a new tactic in order to keep developing stuff that's useful. I could develop bigger and better C modules to do that calculation work. But if I'm doing all the heavy-lifting in C, Python becomes extraneous. I could try to make Python itself much faster and submit some patches, but I suspect there aren't a lot of Really Obvious Speedups I could find. I could try getting my code to run on a "faster Python" like PyPy, but that's some seriously experimental stuff I can't assume everyone will have. I could wait around for hardware to become fast enough to give my Python implementations value, but I might be waiting a long time.
I will continue to ponder this problem. Whether I can solve it and how will determine whether Python Audio Tools will ever evolve beyond their humble metadata-heavy origins into something with a wider purpose.
2007-12-05 01:56:04 UTC by tuffy
-
FLAC vulnerabilities and the Python Audio Tools
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.
Vulnerabilities 1, 2, 3, 4, 7, 8, 9 and 12 rely on overflowing malloc(3) by assuming the FLAC decoder will allocate an excessive amount of memory at once prior to filling it. My implementation essentially passes that size argument to Python's read() function call, which doesn't implement large amounts of memory at once and cannot exceed the length of the file.
Vulnerabilities 5 and 6 rely on errors in image handling. Python Audio Tools actually ignores all image metadata fields except when displaying such information via the trackinfo executable or choosing filenames. The image data itself is fed to PyGTK which does the actual image rendering work. Unless PyGTK contains any image parsing vulnerabilities, invalid FLAC image metadata should cause no harm.
Vulnerabilities 10 and 11 exploit FLAC external file capabilities via the '-->' MIME type. Python Audio Tools does not support these (nor have I ever seen such files in the wild). It will not download any external files. I may implement this portion of the spec at some point, but it is currently nonfunctional and harmless.
Vulnerabilities 13 and 14 exploit FLAC's seektable. Since Python Audio Tools does not use FLAC's seektable in any way, one would be vulnerable only if there are some bugs in the "flac" executable itself.
I hope this will ease any fears anyone might have about Python Audio Tool's FLAC handling capabilities. But if anyone finds a possible exploit I may have missed, please contact me at once so I can fix the problem with timely bugfixes.
2007-11-20 02:57:28 UTC by tuffy
-
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.
2007-11-10 20:31:12 UTC by tuffy
-
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.
Though I haven't added peak support yet, I'm surprised how easy it was to implement.
2007-11-03 23:13:17 UTC by tuffy
