A Modest Construct

Posts tagged `codecs`

¶ Tracking LZMA efficiency

I’m a big fan of 7-Zip. It isn’t the best-looking application ever written, but that could be because its creator, Igor Pavlov, is concerned much more with its compression methods than its interface. 7-Zip has its own container format, but more important is the LZMA compression algorithm that Igor wrote and put into the public domain.

I decided to do some quick and dirty benchmarks to track the progress of LZMA/7-Zip over time. I went back as far as Igor supplied binaries, including one from the very old 3.x series. Rather than test every single release between then and now, I used only “stable” releases, with the exception of version 4.65, which is the latest version of any sort, as well as 4.66, which uses an alpha version of Igor’s new LZMA2 codec (and, as you’ll see, provides definite performance improvement).

I used Igor’s Timer utility to time the process (global time was reported). The corpus in this case was the Linux kernel source, v2.6.28. I conducted these tests on a RAM disk to eliminate hard disk latency issues (especially for decompressions, which improved by about 25% from my initial HDD-based tests). My rig is a Intel Core 2 Quad Q6600 [2.4Ghz], with 4GB of RAM (one dedicated to the RAM disk), running Vista SP1 x64.

The command line setup was an approximation of the 7-Zip GUI’s “ultra” settings: -t7z -m0=lzma -mx=9 -mfb=64 -md=32m -ms=on, letting the archiver auto-choose the number of threads to spawn. Read more…

§3580 · February 9, 2009 · 1 comment · Tags: benchmarks, codecs, compression, Linux, open source, software

¶ FLAC compile benchmarks

FLAC is a cross-platform codec, but when it comes to Windows, one has a pretty wide range of compiles. Some are more optimized than others.

I first got the idea for this benchmark when I stumbled upon a native 64-bit FLAC executable for Windows. Curious, I did a quick and dirty test against the canonical build for Windows and found that while encoding times were similar, decoding times were considerably faster.

To figure out why this is so (the 64-bitness or something else), I quickly pulled some some additional compiles and benchmarked them against a few different samples.

¶ GNOME Audio Player Shootout Revisited

GNOME logo

It’s been close to two years since I wrote GNOME Audio Player Shootout, a visual and textual comparison of some the best available audio players for the GNOME desktop.

As is usually the case in the world of free software, a lot has happened since then (and yet, in a strange way, things have stayed exactly the same). I decided to revisit some of those players and see how they’ve progressed. Some of them listed last time haven’t seen any appreciable development, and have been left off.

I realize that I am totally ignoring the daemon-based players (read: Music Player Daemon, XMMS2); this is by design, since those players open up a whole new can of worms. Suffice it to say that if you’ve decided on and XMMS2 or MPD-based player and successfully configured it, you probably don’t need any advice on choosing software.

The following programs will be covered in this review (development versions):

BMPx (0.40.14)
Rhythmbox (0.11.6)
Exaile (2.99.1-svn)
Banshee (1.4.1)
Quod Libet (2.0)
Decibel (1.00)
Songbird (1.0)
Listen (0.6~svn1044)

All of the testing was done on a fresh install (and update) of Ubuntu 8.10 in VirtualBox, using a small representative sample of my music collection (some modern, some classical, in Vorbis, MP3, and FLAC).

§2709 · December 19, 2008 · 4 comments · Tags: audio, codecs, Firefox, FLAC, GNOME, Linux, open source, software

Pages: 1 2 3 4 5 6 7 8 9 10

¶ cdrtfe: a powerful cdrtools frontend

Previously, I reviewed InfraRecorder, a relatively young project that seeks to add a bit of spit and polish to the venerable cdrtools command line programs. At the time, noted that while the interface was lovely, there were a few flaws, notably the hassle of add-on mp3 support, the lack of FLAC support, and limited flexibility.

Another frontend, cdrtfe (cdrtools frontend), was a freeware project that fairly recently opened its source, and I’ve been using it ever since. It hasn’t got the best interface in the world, but it’s one of the most powerful little programs I’ve seen in a long time.

Please note that the version of cdrtfe that I use is 1.3pre1 which is not the stable 1.2x series. Any bugs which I describe should not be ascribed to the stable series, but considered bugs in development until proved otherwise.

¶ Infra Recorder: the best Windows cdrtools frontend

Infra Recorder

The state of Win32 burning programs

The proprietary choices for optical disc burning on Windows are pretty obvious: at the fore, there’s Roxio’s offering, EZ Media Creator, and Nero’s offering, Nero Burning Rom. Having used Roxio’s v5 program long, long ago with my Hewlett-Packard 4x external CDRW drive, and having used Nero’s Burning Rom during the entirety of its v6 lifecycle (when it was one of the best offerings on the market), I’ve been disappointed to see most of these offerings turn into bloated creatures, invasive and slow.

Perhaps you want built-in picture managers, movie players, reencoders, editors, and every bang and whistle you can think of. If that’s your bag, baby, you’re more than welcome to shell out $80+ for a copy

My time on Linux, however, has engendered me to the rock-solid (if historically murky in license) cdrtools, especially since the wonderful k3b is essentially a cdrtools frontend.

Historically, frontends for Windows have been touch & go. Burnatonce, a freeware closed-source frontend, which two years ago was a great little minimalist project, has stagnated, as the developer has no clear roadmap for development or time to create one.

The functional but less-glamorous cdrtfe is another good solution, although my experiences with it have been limited.