0

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?

Improve this question
6
  • 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, 2015 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, 2015 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, 2015 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, 2015 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.
    – n00dles ♦
    Jun 14, 2015 at 0:00

2 Answers 2

Reset to default
1

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...

Improve this answer
0

Lossy codecs can not be as fast as you might think they can. Depending on the decoder, MP3 is generally about 2x faster to decode than OGG, and is probably the most optimized any such codec can be. But FLAC is much faster because it is lossless and the decompression process is relatively straight forward and can be multi-threaded.

If you need speed, you need codecs that are simpler than MP3/OGG. Or highly accelerated custom-built decoders that utilize GPU power or something. ADPCM is one way to achieve lossy compression with fast decoding, but most ADPCM schemes have worse efficiency and quality compared to FLAC.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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