I have an application that requires reading long (8h) compressed audio files. The quality and size of the file is not the main concern, but the time it takes to decode the full file is. WAV file does actually load pretty fast (despite the IO time required to load 700MB file), while OGG will produce a 7 times smaller file, but it will take much longer to load and the bottleneck will mostly be CPU.

I was wondering what would be the "fastest" codec in terms of decoding, that would still perform some lossy audio compression? Is there some middle ground here?

  • Do you read the 700 MB file in one shot or do you bufferize it ? Can you give an order of what 'much longer' means ? Are you using a library for decoding or are you implementing decoding yourself ? Are your input files monophonic or multi-channel ? – audionuma Jun 10 '15 at 5:29
  • I would say it takes about 4-5 times longer to read the OGG than WAV. I am using people.csail.mit.edu/hubert/pyaudio to do it. The file is 11khz, 1 channel. – Andrzej Pronobis Jun 10 '15 at 5:59
  • 11 kHz is the sampling frequency ? What about the quantization ? Do you need to playback the file or just parse it to process audio data ? First clue for performance issue is the use of the python PortAudio binding which is probably not the most adapted and efficient software for your task. If your goal is to process audio data, lossy encoding might be an issue as it transforms data. – audionuma Jun 11 '15 at 5:58
  • 1
    I made tests with libsndfile in C and found worse result than yours : flac decoding takes around 12 times wav pcm decoding time, and ogg 128k takes around 15 times wav pcm decoding times. So the python binding is probably not the culprit (at least in terms of relative decoding time). I don't have more clues on a low complexity decoder that would answer your question. – audionuma Jun 11 '15 at 11:39
  • 1
    I think you'd have to do a few tests to figure this one out. Encoding/Decoding times can vary greatly, It's a case of finding the lesser of the evils. – Marc W Jun 14 '15 at 0:00

Compression doesn't necessarily mean quality loss: There are lossless formats that provide reasonable compression, for example Microsoft's WMA format has a lossless variant, there's Apple Lossless, FLAC, even a lossless MP3, all can provide audio compression without any quality loss. Think of it as taking the raw media file and running it through ZIP. The compression consumes resources but doesn't degrade quality.

On the other hand, lossy shrinking of media files can be achieved without any compression: You can resample the media at a lower sample rate, less bits per sample, mono instead of stereo or surround, etc.

When you consider the issue of computational efficiency vs. quality there are actually many more parameters to take into consideration. For example, a codec used mainly for speech (e.g., in phones or voice chat) addresses a different dynamic range than that of a music codec, and therefore the efficiency vs. quality measurements are quite different.

So what is the perfect "middle-ground" as you call it? It is up to you to define. Most modern codecs can be calibrated to suit your target efficiency in terms of storage-CPU-quality ratios by controlling many aspects of the encoding. The AAC format even standardized a set of formal "profiles" that combine some perfect "middle ground", each perfect for a specific task.

All that said, looking for the "best" codec isn't just a matter of format. Most formats typically have several implementations, and as we know some programmers are good, some are even better...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.