Hydrogenaudio Knowledgebase - User contributions [en]

High Definition Compatible Digital

2016-07-03T04:22:01Z

Saratoga: clarify what the ffmpeg options do

'''High Definition Compatible Digital''', or '''HDCD''' is a Microsoft proprietary audio encode-decode process that claims to provide increased dynamic range over that of standard Redbook audio CDs, while retaining backward compatibility with existing Compact disc players. —[https://en.wikipedia.org/wiki/High_Definition_Compatible_Digital HDCD article at Wikipedia]

HDCD encodes a virtual 20-bit audio stream in the 16-bit redbook audio stream. Decoding the extra information required an HDCD-compatible player or Windows Media Player. There was no public documentation for the process, but it was eventually reverse engineered. Many HDCD-encoded CDs were released from the mid 1990s until about 2008. Microsoft no longer advertises nor supports HDCD.

A lossless copy of CD audio will include the HDCD data.

== Links ==

* [http://www.head-fi.org/t/65414/hdcd-list List of known HDCD compact discs] at Head-Fi.org
* Technical examination by Jim Lesurf: [http://www.audiomisc.co.uk/HFN/HDCD/Enigma.html Page 1] [http://www.audiomisc.co.uk/HFN/HDCD/Examined.html Page 2]

== Decoding software ==
As HDCD is a proprietary extension owned by Microsoft, Windows Media Player was the only software to support it for a long time. A simple closed-source Windows-only decoding tool, called hdcd.exe, appeared in 2007 on the Doom9 Forum, a product of reverse-engineering Windows Media Player. [http://forum.doom9.org/showthread.php?t=129136] Since that time, an open source implementation has come to exist based on this work. It supports the peak extend and gain HDCD features, while the transient filter feature is detected but not implemented.

=== Audio players ===
* Windows Media Player, but there is a bug where HDCD will not be enabled if the HDCD control signal is not detected near the beginning of a song
* [[Foobar2000]] can decode HDCD to 20-bit PCM via [[Foobar2000:Components/HDCD Decoder (foo dsp hdcd)|foo_dsp_hdcd]] ([https://github.com/kode54/foo_hdcd/blob/master/hdcd_decode.c source])
* [[dBpoweramp]] will decode HDCD to 24-bit PCM
* [[CUETools]]

=== FFmpeg ===
FFmpeg version 3.1's libavfilter supports a HDCD filter that will convert HDCD-encoded audio to PCM at up to 20-bit precision. The filter is based on the Foobar2000 component source code.

;Example:FLAC with HDCD encoded in 16-bit (perhaps ripped from a CD)
ffmpeg -i input16.flac -af hdcd output24.flac
;Example 2:Notice the output from the filter is truncated down to 16-bit because the wav muxer defaults to pcm_s16le...
ffmpeg -i input16.wav -af hdcd output16.wav
;Example 3:... if you want to use another format (like pcm_s24le), you have to specify it with the acodec option
ffmpeg -i input16.wav -af hdcd -acodec pcm_s24le output24.wav

Transparency

2012-09-10T23:57:54Z

Saratoga: don't explain how to scientifically prove something is true that is also subjective since that would be nonsense

In [[psychoacoustics]], '''transparency''' is the ideal result of [[lossy]] data compression. If a lossily compressed result is perceptually indistinguishible from the uncompressed input, then the compression can be declared to be transparent. In other words, transparency is the situation where [[artifact]]s are nonexistant or imperceptible.

Transparency depends most on the listener's familiarity with artifacts, and to a lesser extent, the compression method, [[bitrate]] used, input characteristics, listening conditions, and listening equipment. It also depends, on the particular music piece or sound under examination. Some audio samples, when compressed with certain algorithms under certain conditions, are known to cause artifacts of a specific kind (see, for example, the samples from the [http://lame.sourceforge.net/quality.php Lame MP3 Encoder Quality and Listening Test Information web page]).

Judging transparency can be difficult due to observation bias, in which subjective like/dislike of a certain compression methodology emotionally influences his/her judgment. This bias is commonly referred to as ''placebo,'' although this use is slightly different from the medical use of the term.

By definition, there is no way to prove whether a certain compression methodology is transparent. To scientifically prove that a compression method is ''not'' transparent, one should either show that the particular compression method results in a measurable and easily perceived artifact, or use double-blind tests where the high anchor is the original uncompressed audio. For such tests the [[ABX]] method is normally used, and the audio samples should be chosen so as to make the detection of artifacts more obvious.

Non-lossy compression algorithms are assumed to be transparent: a non-lossy compression methodology should never introduce any artifact.

Transparency at the lowest possible bitrate also seems to be used as a measure of the quality or degree of sophistication and tuning of a lossy compression algorithm:
* MP3-encoded files are generally considered artifact-free at bitrates at/above 192kbps.
* Vorbis ogg files are supposedly artifact-free at bitrates at/above 160kbps.
* AAC-encoded files, depending on the particular encoder implementation, are claimed to be artifact-free at lower bitrates than both Vorbis ogg and MP3.

With the present competition between compression formats (open and proprietary) and encoder implementations (GPL'd, proprietary), any claims of transparency at any given bitrate should always be considered with some skepticism.

[[Category:Listening Tests]]

Transparency

2012-09-10T23:51:30Z

Saratoga:

In [[psychoacoustics]], '''transparency''' is the ideal result of [[lossy]] data compression. If a lossily compressed result is perceptually indistinguishible from the uncompressed input, then the compression can be declared to be transparent. In other words, transparency is the situation where [[artifact]]s are nonexistant or imperceptible.

Transparency depends most on the listener's familiarity with artifacts, and to a lesser extent, the compression method, [[bitrate]] used, input characteristics, listening conditions, and listening equipment. It also depends, of course, on the particular music piece or sound under examination. Some audio samples, when compressed with certain algorithms under certain conditions, are known to cause artifacts of a specific kind (see, for example, the samples from the [http://lame.sourceforge.net/quality.php Lame MP3 Encoder Quality and Listening Test Information web page]).

Judging transparency can be difficult due to observation bias, in which subjective like/dislike of a certain compression methodology emotionally influences his/her judgment. This bias is commonly referred to as ''placebo,'' although this use is slightly different from the medical use of the term.

By definition, there is no way to prove whether a certain compression methodology is transparent, since transparency is a perceptual, subjective phenomenon. To scientifically prove that a compression method is ''not'' transparent, one should either show that the particular compression method results in a measurable and easily perceived artifact, or use double-blind tests where the high anchor is the original uncompressed audio. For such tests the [[ABX]] method is normally used, and the audio samples should be chosen so as to make the detection of artifacts more obvious.

Non-lossy compression algorithms are assumed to be transparent: a non-lossy compression methodology should never introduce any artifact.

Transparency at the lowest possible bitrate also seems to be used as a measure of the quality or degree of sophistication and tuning of a lossy compression algorithm:
* MP3-encoded files are generally considered artifact-free at bitrates at/above 192kbps.
* Vorbis ogg files are supposedly artifact-free at bitrates at/above 160kbps.
* AAC-encoded files, depending on the particular encoder implementation, are claimed to be artifact-free at lower bitrates than both Vorbis ogg and MP3.

With the present competition between compression formats (open and proprietary) and encoder implementations (GPL'd, proprietary), any claims of transparency at any given bitrate should always be considered with some skepticism.

[[Category:Listening Tests]]

Frequency analysis

2012-05-14T05:02:57Z

Saratoga: fixed formatting on links

;Why Shouldn't We Use Frequency or Spectral Graphs to Compare Audio Codecs?

# You can't know precisely what is audible and what is not audible just by looking at graphs. ''(Remember: It's '''music''' that we are talking about.)''
# [[FFT]] [[frequency]] response graphs are rough and can't tell practically anything about the temporal (short time) accuracy.
# All psychoacoustic models are different. What can look good in graphs, doesn't necessarely sound too good and vice versa.
# Graphical analysis is often useful, but only when used together with a listening test. The most useful view is the sound spectra view (spectral view in [[Adobe Audition]]).
# Blind listening testing ([[ABX]]) is the only method that can really be justified when testing quality. Blind testing, when enough probability is reached, is not affected by anykind of bias or [[placebo effect]].
# Difference/substraction/inverse-mixing method is not conclusive either.

;See the following links for more discussion:
* [http://www.hydrogenaudio.org/forums/index.php?showtopic=4734 Why subtracting one waveform from another is not a good analysis of encoding]
* [http://www.hydrogenaudio.org/forums/index.php?showtopic=754 Why merely comparing waveforms is not really effective]
* [http://www.hydrogenaudio.org/forums/index.php?showtopic=7834 Why waveforms cannot be used to deduce quality, but may be useful to know what the encoder is doing]

Dither

2012-03-22T01:15:21Z

Saratoga: improve description of dither

Dither is random or semi-random noise added to a signal in order to mask quantization noise and/or extend dynamic range. The simplest dither is quiet white noise, but more complicated forms of dither are possible using [[noise shaping]], and they can even be completely inaudible.

==Bit depth reduction==
A common use for dither is to improve the perceived audio quality when converting a digital signal from a higher bit depth to a lower one, e.g. from 24-bit to 16-bit. By dithering the signal with a small amount of added noise, the additional rounding error added from requantization can be decorreated from the signal, resulting in a noise floor that is mathematically slightly higher, but audibly less noticeable. The addition of dither becomes more important as the number of quantization levels decreases, and so is particularly important when converting to 8 bit or lower audio.

From [http://www.hydrogenaudio.org/forums/index.php?showtopic=87045&view=findpost&p=745851 a HydrogenAudio forum post] by AndyH-ha:

"When you reduce bit depth there will be resulting distortion. This has two aspects, the change (error) in the waveform itself and an unpleasant addition to the sound because of the error. The waveform error is expressed in the output signal as noise, but noise related to (correlated to) the audio from which it is derived. This is a quality of noise that is generally found to be unpleasant.

"Adding dither before reducing the bit depth randomizes the error. This completely eliminates the unpleasant sound aspect of the error. Instead it will result in a benign white noise kind of background sound. There is thus new noise from two sources in the bit depth reduced audio. The first is the dither noise added prior to bit reduction. The second is the error noise (quantization error) of the bit reduction process. Without the first, randomizing noise, the second noises add an unpleasant aspect to the audio. With the dither, the total noise is much less objectionable than the quantization noise alone.

"This is mathematically correct, and observable with the proper equipment. It is doctrinally correct in the church of quality audio: always add dither when reducing the bit depth. However, I challenge you or anyone else to be able to ABX any real 16 bit music, dithered against non-dithered — unless perhaps some really bad software is used to do the bit reduction. Going to lower bit depths, such as to 8 bit, frequently makes the dither vs non-dither difference obvious and so this is the way it is demonstrated."

==Is dither really necessary?==

Going from 24-bit to 16-bit, the quantization error is very small and the distortion/noise is extremely unlikely to be heard in any real music. Since quantization error isn’t audible in any real music at useable listening levels, whether dither must be used is more a matter of doctrine than functionality.

Many sources (e.g. cassettes and LPs) already have considerable noise such as tape hiss. Even the best live recordings get some noise from the equipment, especially microphone preamplifiers. This might not make the best dither, but it acts in the same way, to largely de-correlate the quantization error from the signal.

Anyone who believes dither is always necessary for conversions to 16-bit should submit, on the HydrogenAudio forums, samples that can be discriminated in blind testing.

{{stub}}

Dither

2012-03-22T01:05:03Z

Saratoga: revert questionable edits

Dither is random or semi-random noise added to a signal in order to mask quantization noise and/or extend dynamic range. The simplest dither is quiet white noise, but more complicated forms of dither are possible using [[noise shaping]], and they can even be completely inaudible.

==Bit depth reduction==
A common use for dither is to improve the perceived audio quality when converting a digital signal from a higher bit depth to a lower one, e.g. from 24-bit to 16-bit.

From [http://www.hydrogenaudio.org/forums/index.php?showtopic=87045&view=findpost&p=745851 a HydrogenAudio forum post] by AndyH-ha:

"When you reduce bit depth there will be resulting distortion. This has two aspects, the change (error) in the waveform itself and an unpleasant addition to the sound because of the error. The waveform error is expressed in the output signal as noise, but noise related to (correlated to) the audio from which it is derived. This is a quality of noise that is generally found to be unpleasant.

"Adding dither before reducing the bit depth randomizes the error. This completely eliminates the unpleasant sound aspect of the error. Instead it will result in a benign white noise kind of background sound. There is thus new noise from two sources in the bit depth reduced audio. The first is the dither noise added prior to bit reduction. The second is the error noise (quantization error) of the bit reduction process. Without the first, randomizing noise, the second noises add an unpleasant aspect to the audio. With the dither, the total noise is much less objectionable than the quantization noise alone.

"This is mathematically correct, and observable with the proper equipment. It is doctrinally correct in the church of quality audio: always add dither when reducing the bit depth. However, I challenge you or anyone else to be able to ABX any real 16 bit music, dithered against non-dithered — unless perhaps some really bad software is used to do the bit reduction. Going to lower bit depths, such as to 8 bit, frequently makes the dither vs non-dither difference obvious and so this is the way it is demonstrated."

==Is dither really necessary?==

Going from 24-bit to 16-bit, the quantization error is very small and the distortion/noise is extremely unlikely to be heard in any real music. Since quantization error isn’t audible in any real music at useable listening levels, whether dither must be used is more a matter of doctrine than functionality.

Many sources (e.g. cassettes and LPs) already have considerable noise such as tape hiss. Even the best live recordings get some noise from the equipment, especially microphone preamplifiers. This might not make the best dither, but it acts in the same way, to largely de-correlate the quantization error from the signal.

Anyone who believes dither is always necessary for conversions to 16-bit should submit, on the HydrogenAudio forums, samples that can be discriminated in blind testing.

{{stub}}

Original ReplayGain specification

2011-08-14T20:00:14Z

Saratoga: /* Metadata format */

Although music is encoded to a digital format with a clearly defined maximum peak amplitude, and although most recordings are normalized to utilize this peak amplitude, not all recordings sound equally loud. This is because once this peak amplitude is reached, perceived loudness can be further increased through signal-processing techniques such as dynamic range compression and equalization.<ref>Source: Wikipedia - [http://en.wikipedia.org/wiki/Loudness_war Loudness war]</ref> Therefore, the loudness of a given album has more to do with the year of issue or the whim of the producer than the intended emotional effect. Because of this, a random play through a music collection can have one leaping for the volume control every other track.

There is a solution to this annoyance: within each audio file, information can be stored about what volume change would be required to play each track or album at a standard loudness, and players can use this "replay gain" information to automatically nudge the volume up or down as required.

The ReplayGain specification is a standard which defines an appropriate reference level, explains a way of calculating and representing the ideal replay gain for a given track or album, and provides guidance for players to make the required volume adjustment during playback. The standard also specifies a means to prevent clipping when the calculated replay gain exceeds the limits of digital audio, and it describes how the replay gain information is stored within audio files.

==Loudness measurement==
Loudness is a subjective measure of the intensity of sound. The correlation of perceived loudness to sound pressure level is determined by the peculiarities of the auditory system. ReplayGain attempts to model those peculiarities with the following measurement procedure.

===Loudness filter===
[[File:RG_Equal_loudness_all.gif‎|frame|Figure 1: Loudness filter target response (blue), high-pass response (green) and composite response (red)]]

The human ear does not perceive sounds of all frequencies as having equal loudness. For example, a full-scale sine wave at 1 kHz sounds much louder than a full scale sine wave at 100 Hz, even though the two have identical energy. To account for this, the signal is filtered by an inverted approximation of the equal loudness curves (sometimes referred to as Fletcher–Munson curves) which describe the sensitivity of the ear as a function of frequency. The desired filter response derived from the equal loudness curves is shown in figure 1 (blue).

At higher frequencies a 10th order IIR filter designed by MATLAB's "yulewalk" function is an excellent approximation to the target. This is cascaded with a 2nd order Butterworth high pass filter, with a high pass frequency of 150 Hz (Figure 1 [green]). The resulting combined response (Figure 1 [red]) is close to the target response, and is used by ReplayGain.

[[File:RG_IIR-filter.png|frame|Figure 2: IIR filter topology used by "yulewalk" and Butterworth filter components]]

The filter topology used for the components of the loudness filter is shown in figure 2. The filter coefficients for 48 and 44.1 kHz sample rates are given for the Butterworth and "yulewalk" components in tables 1 and 2 respectively. When using other sample rates, coefficients must be transformed to maintain the same filter response.

{| class="wikitable" style="text-align:center"
|+Table 1a: Butterworth filter coefficients (Fs=48 kHz)
|-
| colspan="2" |
| ''b(0)''
| 0.98621192462708
|-
| ''a(1)'' || 1.97223372919527 || ''b(1)'' || -1.97242384925416
|-
| ''a(2)'' || -0.97261396931306 || ''b(2)'' || 0.98621192462708
|-
|}

{| class="wikitable" style="text-align:center"
|+Table 1b: Butterworth filter coefficients (Fs=44.1 kHz)
|-
| colspan="2" |
| ''b(0)''
| 0.98500175787242
|-
| ''a(1)'' || 1.96977855582618 || ''b(1)'' || -1.97000351574484
|-
| ''a(2)'' || -0.97022847566350 || ''b(2)'' || 0.98500175787242
|-
|}

{| class="wikitable" style="text-align:center"
|+Table 2a: "Yulewalk" filter coefficients (Fs=48 kHz)
|-
| colspan="2" |
| ''b(0)''
| 0.03857599435200
|-
| ''a(1)'' || 3.84664617118067 || ''b(1)'' || -0.02160367184185
|-
| ''a(2)'' || -7.81501653005538 || ''b(2)'' || -0.00123395316851
|-
| ''a(3)'' || 11.34170355132042 || ''b(3)'' || -0.00009291677959
|-
| ''a(4)'' || -13.05504219327545 || ''b(4)'' || -0.01655260341619
|-
| ''a(5)'' || 12.28759895145294 || ''b(5)'' || 0.02161526843274
|-
| ''a(6)'' || -9.48293806319790 || ''b(6)'' || -0.02074045215285
|-
| ''a(7)'' || 5.87257861775999 || ''b(7)'' || 0.00594298065125
|-
| ''a(8)'' || -2.75465861874613 || ''b(8)'' || 0.00306428023191
|-
| ''a(9)'' || 0.86984376593551 || ''b(9)'' || 0.00012025322027
|-
| ''a(10)'' || -0.13919314567432 || ''b(10)'' || 0.00288463683916
|-
|}

{| class="wikitable" style="text-align:center"
|+Table 2b: "Yulewalk" filter coefficients (Fs=44.1 kHz)
|-
| colspan="2" |
| ''b(0)''
| 0.05418656406430
|-
| ''a(1)'' || 3.47845948550071 || ''b(1)'' || -0.02911007808948
|-
| ''a(2)'' || -6.36317777566148 || ''b(2)'' || -0.00848709379851
|-
| ''a(3)'' || 8.54751527471874 || ''b(3)'' || -0.00851165645469
|-
| ''a(4)'' || -9.47693607801280 || ''b(4)'' || -0.00834990904936
|-
| ''a(5)'' || 8.81498681370155 || ''b(5)'' || 0.02245293253339
|-
| ''a(6)'' || -6.85401540936998 || ''b(6)'' || -0.02596338512915
|-
| ''a(7)'' || 4.39470996079559 || ''b(7)'' || 0.01624864962975
|-
| ''a(8)'' || -2.19611684890774 || ''b(8)'' || -0.00240879051584
|-
| ''a(9)'' || 0.75104302451432 || ''b(9)'' || 0.00674613682247
|-
| ''a(10)'' || -0.13149317958808 || ''b(10)'' || -0.00187763777362
|-
|}

Input samples from the audio file to be analysed must be run in cascade manner through both of these filter components before being analysed further.
 

===RMS level calculation===
Next, the energy during each moment of the signal is determined by calculating the Root Mean Square (RMS) of the filtered signal every 50ms.<ref>The block length of 50ms was chosen after studying the effect of values between 25ms and 1s. 25ms was too short to accurately reflect the perceived loudness of some sounds. Beyond 50ms there was little change (after statistical processing). For this reason, 50ms was chosen.</ref>

The signal is chopped into 50ms long blocks. Then, for each block:<ref>If these steps are read backward, it should be clear why the process is called Root Mean Square averaging.</ref>
# Every sample value is squared (multiplied by itself).
# The mean average is taken.
# The square root of the average is calculated.

For stereo signals, in step 3, the mean average of all squared samples from both channels over the 50ms measurement interval is taken.<ref>One could sum channels of a stereo signal to mono before calculating the RMS level, but then any out-of-phase components (having the opposite signal on each channel) would cancel out to zero (i.e. silence). That's not how humans perceive them, so it's not a good solution.</ref>

The result of this calculation is then converted to a decibel representation as follows:

:<math>L=20 \log_{10} \frac{2{L_{RMS}}}{L_{p-p}}</math>

Where:

:<math>L_{RMS}</math> is the RMS value calculated above
:<math>L_{p-p}</math> is the maximum peak-to-peak range of the samples in the audio file

===Statistical processing===
Where the average energy level of a signal varies with time, the louder moments contribute most to perception of overall loudness. For example, in human speech, over half the time is silence, but the perceived loudness of speech is primarily determined by the levels between silences.

A good method to determine the overall perceived loudness is to sort the RMS values into numerical order, and then pick a value near the top of the list. For highly compressed pop music (e.g. Figure 5(c), where there are many values near the top), the choice makes little difference. For speech and classical music (Figures 5(a) and 5(b) respectively), the choice makes a huge difference. The value which most accurately matches human perception of perceived loudness is 95%,<ref>Based on experiments performed by David Robinson, "I tried values from 70% to 95%. For highly compressed pop music, the choice makes little difference. For speech and classical music, the choice makes a huge difference. The value which most accurately matches human perception of perceived loudness is around 95%, so this value is used by Replay Level."</ref> so this value is used by ReplayGain.

<gallery caption="Figure 5: Loudness histograms">
File:RG_Statistical_speech.gif‎‎|(a) Speech
File:RG_Statistical_classic.gif‎‎|(b) Classical music
File:RG_Statistical_pop.gif‎‎|(c) Pop music
</gallery>

==Reference level==
The audio industry does not have a standard for playback system calibration, but in the movie industry a calibration standard has been defined by the Society of Motion Picture and Television Engineers (SMPTE).<ref>SMPTE RP 200:2002 – Relative and Absolute Sound Pressure Levels for Motion-Picture Multichannel Sound Systems – Applicable for Analog Photographic Film Audio, Digital Photographic Film Audio and D-Cinema</ref> The standard states that a single channel pink noise signal with an RMS level of -20 dB relative to a full-scale sinusoid<ref>"dB relative to a full-scale sinusoid" is preferred over "dBFS" as a unit of measure in this specification because there is some ambiguity whether the reference for dBFS is a full-scale square wave (peak reference) or a sine wave (RMS reference).</ref> should be reproduced at 83 dB SPL.<ref>Measured using a C-weighted, slow averaging SPL meter.</ref>

ReplayGain adapts the SMPTE calibration concept for music playback. Under ReplayGain, audio is played so that its loudness, as measured using the procedures described in [[#Loudness measurement|Loudness measurement]] above, matches the loudness of a pink noise signal with an RMS level of -14 dB relative to a full-scale sinusoid,<ref>The initial ReplayGain proposal used the same -20 dB reference used by SMPTE. The reference was raised to -14 dB early on in ReplayGain development. This reference is used in all current ReplayGain implementations.</ref> also measured using the procedures described above.

In ReplayGain implementations, the reference level is described in terms of the SMPTE SPL playback level. By the SMPTE definition, the 83 dB SPL reference corresponds to -20FS dB system headroom. The -14 dB headroom used by ReplayGain therefore corresponds to an 89 dB SPL playback level on a SMPTE calibrated system and so is said to be operating with an 89 dB reference level.

SMPTE cinema calibration calls for a single channel of pink noise reproduced through a single loudspeaker. In music applications, the ideal level of the music is actually the loudness when both speakers are in use. So, ReplayGain is calibrated to two channels of pink noise.<ref>In reality, a monophonic pink noise wave file is used, and ReplayGain automatically assumes the file is being played through both speakers, as would any monophonic file.</ref>

==Gain calculation==
RG achieves loudness compensated playback by applying gain (or attenuation) dependent on the measured loudness of the audio file relative to the established reference level. The gain is calculated as follows:
:<math>RG=L_{n14}-L</math>
Where all quantities are expressed in decibels:
:<math>RG</math> is the replay gain adjustment,
:<math>L_{n14}</math> is the measured loudness of the -14 dB pink noise reference and
:<math>L</math> is the measured loudness of the audio file.

Replay gain is positive if the loudness of the audio file is lower than the pink noise reference. The gain is negative (representing an attenuation) if the loudness of the audio file is higher than that of the reference. The gain is stored as metadata with the audio file as described below and is used by players to adjust output volume of tracks as they are played as described in [[#Player requirements|Player requirements]] below.

==Metadata==
For ReplayGain to do its work during playback, four values must be stored as metadata<ref>Metadata is "data about data." For example, the ID3 ''de facto'' standard provides a way to store artist, title, album title, track number, and other metadata in data blocks called "tags" immediately before or after the audio data in an MP3 file. Other metadata storage/tagging standards and conventions exist for other audio file formats.</ref> with or within the audio file:
# Peak track amplitude
# Peak album amplitude
# Track replay gain
# Album replay gain

If calculated for an individual track, the loudness measurement (as specified above) yields track replay gain. If calculated on an album basis, with all tracks concatenated to make one long audio file, the loudness measurement yields album replay gain.

===Replay gain===
Under some listening conditions, it's useful to have every track sound equally loud. The problem with a track-by-track approach is that tracks which should be quiet in the context of the album on which they reside will be brought up to the level of all the rest. For casual listening, or in a noisy background, this can be a good thing. For serious listening, it does not respect the intent of the artist or mastering engineer; a tender ballad track will be blasting at the same loudness as a hard rock track on the same album. It's generally ideal to leave the intentional loudness differences between tracks in place, yet still correct for unmusical and annoying loudness differences between albums. To accomplish this, ReplayGain suggests that two different gain adjustments should be stored as metadata with each sound file.

''Album replay gain'' represents the ideal listening gain for an entire album. ReplayGain reads the collection of tracks that comprise a album, and calculates a single replay gain for the whole set. This single gain can be used for playback of all tracks of the album. Intentionally quiet tracks then stay appropriately quieter than the rest. It still solves the basic problem (annoying, unwanted level differences between discs) because quiet or loud discs are still adjusted overall—so the pop CD that's 20 dB louder than the classical CD will be brought into line.

===Peak amplitude===
Scanning a track or album for the peak amplitude can be a time-consuming process. Therefore, it's helpful if this single value is stored as metadata. This is used to predict whether the required replay gain adjustment will cause clipping during playback.

The maximum peak amplitude value is stored as a floating point number, where 1.0 represents digital full scale. As with replay gain values, separate peak amplitude values are stored per track and per album.

For uncompressed files simply, scanners store the maximum absolute sample value held in the file on any channel for positive or negative excursion. The single sample value should be converted to a floating-point representation, such that digital full scale is equivalent to a value of 1.0.

Psychoacoustically coded audio, such as MP3, does not exist as a sequence of samples until it is decoded. Psychoacoustic coding of a heavily limited file can lead to sample values larger than digital full scale upon decoding. The coded files must be decoded using a fully compliant decoder that allows peak overflows (i.e. has headroom) and may result in peak amplitude values greater than 1.0.

==Metadata format==
From the standpoint of metadata storage, each audio file format presents a unique situation. There are three favored schemes defined for storage of ReplayGain metadata: '''ID3v2''', '''Vorbis comments''' and '''APEv2'''. A survey of file formats is listed below with metadata schemes in order of preference for each:
* .aac (Advanced Audio Coding raw format) – No metadata support (use .mp4 instead)
* .aiff, .aif, .aifc (Apple Interchange File Format) – '''ID3v2''' (in "ID3" IFF chunk)
* .ape, .apl (Monkey's Audio) – '''APEv2'''
* .bwf (Broadcast Wave Format) – '''ID3v2''' (in RIFF chunk)
* .flac (Free Lossless Audio Codec) – '''Vorbis comments'''
* .mp3 (MPEG audio layer 3) – '''ID3v2''', LAME VBR proposed tag specification
* .mp4 also .m4a, .m4b, .m4p, m4r (MPEG-4 Part 14) – '''ID3v2''' (in "ID32" box)
* .mpc (Musepack) – '''APEv2'''
* .ogg (Ogg Vorbis) – '''Vorbis comments'''
* .tta (True Audio) – '''ID3v2''', '''APEv2'''
* .wma (Windows Media audio) - In Extended Content Description Object, Vorbis Comment ASCII values
* .wav (Windows PCM) – No metadata support (use .bwf instead)
* .wv (WavePak) – '''APEv2'''

===ID3v2===
The ID3v2 standard<ref>The ID3v2 format is explained at [http://www.id3.org/ www.id3.org]. The most useful document is the [http://www.id3.org/id3v2.3.0.html ID3v2 v2.3.0 standard]. Although this document has been superseded by v2.4.0, the earlier document is complete (rather than an update), and in indexed HTML form. As such, it represents a better technical introduction to ID3v2.</ref> defines a ''tag'' which is situated before the data in an MP3 file.<ref>The original ID3 (v1) tags resided at the end of the file, and contained a few fields of information. The ID3v1 tag is not extensible and therefore cannot support ReplayGain metadata.</ref> ID3 is used primarily with MP3 audio files but means of adapting the system to other file types have been developed.

The ID3v2 tag is divided into ''frames''. The preferred means of storing ReplayGain metadata is use of ''TXXX'' key/value pair frames. Two other legacy schemes for storing ReplayGain metadata exist: [[ReplayGain_legacy_metadata_formats#ID3v2_RGAD|RGAD]] and [[ReplayGain_legacy_metadata_formats#ID3v2_RVA2|RVA2]]. These formats are documented in the [[ReplayGain legacy metadata formats|appendix]]. Players may choose to look for these formats if metadata in the ''TXXX'' format is not found in the ID3v2 tag. New scanners may write these older formats in addition to the newer (TXXX) ones if they wish to remain backwards compatible with older players.

ReplayGain uses four TXXX frames. The header of a TXXX frame is coded as follows:

Frame ID $54 58 58 58 ("TXXX")
Size $xx xx xx xx (size of frame excluding this header)
Flags $40 $00 (discard frame if audio data is altered)

Frame data is coded as follows:

Text encoding $00 (ISO-8859-1 encoding)
Description <key string> $00
Value <value string>

The four frames associated with ReplayGain metadata use the following key/value pairs

{| class="wikitable"
|+Table 3: Metadata keys and value formatting
|-
!Metadata
!Key
!Value format
|-
|Track replay gain
|REPLAYGAIN_TRACK_GAIN
|[-]a.bb dB
|-
|Peak track amplitude
|REPLAYGAIN_TRACK_PEAK
|c.dddddd
|-
|Album replay gain
|REPLAYGAIN_ALBUM_GAIN
|[-]a.bb dB
|-
|Peak album amplitude
|REPLAYGAIN_ALBUM_PEAK
|c.dddddd
|}

Gains are specified textually in decibels. Negative gains (attenuation) are prefixed with a '-'. Positive gains have no prefix. Integral portion of the gain (a) may be one or two numeric (0-9) digits. If there is no integral portion the field is '0'. The decimal portion of the gain (bb) is two numeric digits. Gains are suffixed with a space followed by 'dB'.

Peak levels are specified textually as a positive decimal. Peak level is a dimensionless quantity with 1.000000 representing full scale. No suffix is included on peak values. The integer field (c) is typically 1 or 0. Six numeric digits in the decimal field (dddddd) is adequate to accurately represent peak values for 16-bit audio data.

A robust player should be prepared to parse the following variations in either replay gain or peak level metadata:
*Positive gains with leading '+'
*More or fewer significant digits than specified in any field
*Leading zeros or spaces in integer fields
*Missing or malformed 'dB' suffix (e.g. no space between numeric digits and suffix, alternate capitalization)
*Alternate capitalization of keys

Other formatting errors indicate more severe problems and should result in player ignoring data as if the frame did not exist.

===Vorbis comments===
A Vorbis comment<ref>[http://www.xiph.org/vorbis/doc/v-comment.html Vorbis comment metadata format]. ReplayGain metadata is documented on the [http://wiki.xiph.org/VorbisComment#Replay_Gain Xiph Wiki].</ref> uses an ASCII <tt>key=value</tt> format. When Vorbis comments are used, the four ReplayGain metadata items are stored as separate comments. The ''keys'' and formatting for ''values'' is the same as specified for ID3v2. Keys and values are required by the Vorbis comment specification to b separated by '=' (equal character).

===APEv2===
The APEv2 metadata format<ref>[http://wiki.hydrogenaudio.org/index.php?title=APEv2_specification APEv2 Specification at Hydrogen Audio Wiki]</ref> also organizes data into key/value pairs. Keys are ASCII format. A flags field allows support for several value formats including UTF-8 and binary. Under APEv2, ReplayGain meta data is stored using the same keys and data as ASCII values in the same format as specified for ID3v2.

==Player requirements==
[[File:RG_Player_control.gif‎|frame|Figure 8: Example ReplayGain control panel]]

Loudness normalization, pre-amplification and clipping prevention are the operations performed by a ReplayGain player.

===Loudness normalization===
To properly normalize loudness, the player needs to determine if the user desires Track style level normalization (all tracks same loudness), or Album style level normalization (all albums same loudness, tracks of an album played at the same relative level as on the original release). This option should be selectable in the ReplayGain control panel (Figure 8). The player reads the corresponding gain metadata value from the file and scales the audio data as appropriate. Scaling the audio data simply means multiplying each sample value by a constant value. This constant is given by:

:<math>10^\frac{gain}{20}</math>

Or, in words, replay gain divided by 20 all raised to the power of ten.<ref>After any such operation, it's a good idea to dither the result. If this calculation and the pre-amp are implemented separately, then dither should only be added to the final result, just before the result is truncated back to 16 bits, or 24, or 8, as limited by the soundcard—not the file (i.e. after ReplayGain adjustment, an 8-bit file should be sent to a 16-bit soundcard at 16-bits).</ref>

If the file only contains one of the replay gain adjustments (e.g. Album) but the user has requested the other (Track), then the player should use the one that is available (in this case, Album). If neither (Track or Album) gain metadata is available, then the player needs to choose a suitable default gain. Potential choices include unity gain (0 dB) or an average of gains from other tracks in the album or playlist.

===Pre-amplification===
Although the calibration level used by ReplayGain suggests that the average level of an audio track should be 14 dB below full scale, some pop music is dynamically compressed to peak at 0 dB and average around 3 dB below full scale. This means that, when the replay gain is applied, the level of such tracks will be reduced by 11 dB! If users are listening to a mixture of highly compressed and more dynamic tracks, ReplayGain will make the listening experience more pleasurable by bringing the level of the compressed tracks down into line with that of the others. However, if users are only listening to highly compressed music, then they may complain that all their files are now too quiet.<ref>This problem can be especially noticeable on portable players with limited output or gain.</ref>

To address this problem, a pre-amp feature should be incorporated into the player. A user-supplied pre-amp setting is an adjustment to the calculated replay gain. It should default to perform no adjustment. This means that casual users will experience a moderate reduction in the loudness of their compressed pop music. Less-compressed material can generally be played at the same loudness without clipping. Normalization of more dynamic material may cause clipping or invoke the [[#Clipping prevention|clipping prevention]] mechanism (see below). Power users and audiophiles can reduce the pre-amp gain to enjoy the full dynamic range of all of their music.

If enabled, the player should read the user selected pre-amp gain, and scale the audio signal by the appropriate amount. For example, a +6 dB gain requires a scale of 106/20, which is approximately 2. The replay gain and pre-amp scale factors can be combined<ref>Scale factors in Decibel units are added to produce the same effect as multiplying scale factors in linear units.</ref> for simplicity and ease of processing.

===Clipping prevention===
ReplayGain's suggestion of a -14 dB average playback level leaves sufficient headroom for the bulk of modern recordings. Nevertheless, there exists the possibility that after application of replay gain and pre-amp adjustment, a track may exceed full scale during its dynamic peaks. Without intervention, this will result in clipping, a severe form of distortion. Factors introducing the possibility of clipping include:

# Recordings from certain genres and certain periods in the history or commercial recordings require additional headroom. Although these recordings can be accommodated through a downwards adjustment of the pre-amp setting, it may be difficult to determine a safe adjustment and it may be undesirable to lower average level to accommodate the rare track which requires it.
# ReplayGain will make loud dynamically compressed tracks quieter, and quiet dynamically uncompressed tracks louder. The average levels will then be similar, but the quiet tracks will actually have louder peaks. If the user pushes the pre-amp gain upwards the peaks of the (originally) quieter tracks will be pushed well over full scale.
# In coded audio (e.g. MP3 files) a file that was hard-limited to digital full scale before encoding will often be pushed over the limit by the psychoacoustic compression. A decoder with headroom can recover the over full scale signal by reducing the gain.

ReplayGain suggests two possible solutions which prevent clipping in these situations. A player should support one or both of these.

====Audio limiting====
In situation 2 above, the user clearly wants all the music to sound very loud. To give them their wish, any signal which would peak above digital full scale should be hard limited at just below digital full scale. This is also useful at lower pre-amp gains, where it allows the average level of classical music to be raised to that of pop music, without distorting. The exact type of nature limiting or compression an implementation choice for the player.<ref>Something like the Hard Limiter found in Cool Edit Pro (Syntrillium) would be appropriate for pop music at least.</ref>

====Reduced gain====
The audiophile user will not want any compression or limiting on the signal. In this case the only option is to automatically and temporarily reduce the pre-amp gain below the user-selected setting for tracks where clipping would otherwise occur. Clipping can be predicted by examining the peak level of the track or album being played.

The player must read the peak amplitude metadata. If peak level metadata is unavailable, the player should assume a peak level of 1.0. If the peak level for both track and album is stored as metadata in the file, it is possible to calculate if, following the replay gain adjustment and pre-amp gain, the signal will clip at some point. If it won't, then no further action is necessary.

An overall scale factor for loudness normalization taking into account replay gain, pre-amp setting and clipping prevention through gain reduction is given below.

:<math>min( 10^\frac{RG + G_{pre-amp}}{20}, \frac{1}{peak amplitude} )</math>

===Hardware implementation===
The above three steps are appropriate to software players operating on the digital signal in order to scale it. However, it is possible to send the digital signal to the DAC without level correction, and to place an attenuator in the analogue signal path. The attenuator can then be driven by the Replay Gain value. The clipping problem can be addressed by providing adequate headroom in the analog circuitry. Bit transparency and maximum signal to noise ratio is maintained in the digital signal and DAC process.<ref>A system using today's 24-bit converters is unlikely to appreciate any overall gain in system performance with such an arrangement. A digitally-controlled analog gain element typically introduces significant noise and distortion.</ref>

==Acknowledgements==
The [http://replaygain.hydrogenaudio.org/proposal original ReplayGain proposal] (an [http://replay.waybackmachine.org/20090306202649/http://www.replaygain.org/ archive] is also available) was developed by David Robinson and was published 10 July 2001. Additional updates were published by David Robinson through 10 October 2001.

The following acknowledgement was included with the original proposal, "The algorithm to calculate an ideal replay gain has grown from my research into human hearing, with many additional ideas drawn from the work of E. Zwicker, and Brian Moore. I am currently completing my PhD at the University of Essex, and have been funded by the EPSRC." Additionally David Robinson credited Glen Sawyer (Snelg) and Jim Casaburi (Walrus) for software contributions and Bob Katz and Matt Ashland for ideas.

This updated ReplayGain specification reflecting current and recommended practice was prepared by Kevin Gross in 2011.

==Contact==
For ReplayGain-related questions or contributions, please post in the [http://www.hydrogenaudio.org/forums/index.php?showforum=1 General Audio] section of the Hydrogen Audio forums.

==Appendix==
# [[ReplayGain legacy metadata formats]]

==Notes==
<references />

Rockbox

2011-07-19T15:52:10Z

Saratoga: /* External links */ add rockbox features

{{featured}}
[[Image:Rockboxlogo.png|right]]

'''Rockbox''' is a [[GPL]]-compliant [[open source]] operating system for portable digital audio players (DAPs). The Rockbox Project began in 2002 and was first implemented on the [[Archos]] Studio DAP because of owner frustration with severe limitations in the manufacturer-supplied user interface and device operations.

Rockbox can completely replace the host device's operating system firmware and has matured to become an extensible, flexible platform that provides a plug-in architecture for adding PDA functionality, applications, utilities, and games, and has also managed to retrofit video playback functionality onto DAPs first released in mid-2000. Recently, Rockbox now includes a voice-driven user-interface suitable for operation by blind and visually impaired users.

Although Rockbox's official title is "Rockbox: Open Source Jukebox Firmware", in many instances it is not actually installed to (or run from) flash memory. Instead a minimal bootloader is installed in the supported device's flash which is capable of either loading Rockbox from the hard disk or, alternately, the original factory firmware.

== Codecs ==

Rockbox on software decoding platforms (non-Archos) supports playback of eleven [[lossy compression|lossy]] codecs (depending on how one counts), five [[lossless data compression|lossless]], two uncompressed and six miscellaneous formats.<ref>{{cite web|title=Rockbox Supported audio formats|url=http://download.rockbox.org/daily/manual/rockbox-sansaclipplus/rockbox-buildap2.html#x17-335000B.1|work=Rockbox Manual}}</ref> This makes a conservative total of 25 supported audio formats, although a few of them do not operate in realtime on all platforms. Extensive work has gone into optimizing each codec, with FLAC, Ogg, WMA, APE and WMA Pro among the fastest known implementations for those formats.<ref>{{cite web|url=http://www.hydrogenaudio.org/forums/index.php?showtopic=82125&view=findpost&p=716976 |title=Codec performance comparison – Hydrogenaudio Forums |publisher=Hydrogenaudio.org |date= |accessdate=2011-03-12}}</ref>

=== Lossy formats ===

* MPEG audio layers I-III ([[MP3]]/[[MPEG-1 Audio Layer II|MP2]]/[[MPEG-1 Audio Layer I|MP1]])
* [[Vorbis|Ogg Vorbis]]
* [[Advanced Audio Coding|MPEG-4 AAC]](-LC/HE/HEv2 profiles) (in [[MPEG-4 Part 14|MP4]] or [[RealMedia|RM]] containers)
* [[Musepack]]
* [[Dolby Digital|AC3]] (raw or [[RealMedia|RM]] container)
* [[Windows Media Audio|WMA Standard]]
* [[Windows Media Audio|WMA Professional]]
* [[Speex]]
* [[Cook Codec|Cook]]
* [[Adaptive Transform Acoustic Coding#ATRAC3 (LP2 and LP4 Modes)|ATRAC3]]
* The lossy portion of [[WavPack]] hybrid files

=== Lossless formats ===

* [[Free Lossless Audio Codec|FLAC]]
* [[WavPack]]
* [[Shorten]]
* [[Apple Lossless]]
* [[Monkey's Audio]]
* [[TTA (codec)|TTA]]

=== Uncompressed formats ===

* Intel-style [[WAV]]
* Apple [[Audio Interchange File Format|AIFF]]
Together they include over a dozen different [[Pulse-code modulation|PCM]] and [[Adaptive DPCM|ADPCM]] formats.

== Rockbox features ==

Beside the ability of playing and recording audio files, Rockbox offers many playback enhancements that other firmware packages may not have implemented yet. Listed below are a handful of these features.

* [[Gapless playback]]<ref>{{cite web|title=Codec Featureset|url=http://download.rockbox.org/daily/manual/rockbox-sansaclipplus/rockbox-buildap2.html#x17-339000B.1.4|work=Rockbox Manual|accessdate=22 May 2011}}</ref>
* [[crossfader|Crossfading]]<ref>{{cite web|title=Crossfade|url=http://download.rockbox.org/daily/manual/rockbox-sansaclipplus/rockbox-buildch7.html#x10-1220007.7|work=Rockbox Manual|accessdate=22 May 2011}}</ref>
* [[Replay Gain]]<ref name="soft_decode">Software decoding targets only</ref>
* 5 band fully parametric [[equalization (audio)|equalizer]]<ref name="soft_decode" />
* Variable speed decoding with pitch correction<ref>{{cite web|title=Pitch|url=http://download.rockbox.org/daily/manual/rockbox-sansaclipplus/rockbox-buildch4.html#x7-630004.3.3|work=Rockbox Manual|accessdate=22 May 2011}}</ref>
* [[Crossfeed]]<ref name="soft_decode" />
* OTF ("on the fly") playlists
* True random shuffle (fresh randomly shuffled list every time)
* Custom [[Theme (computing)|UI themes]]
* Dynamic Playlists (queue files to play next, or in other parts of a dynamic playlist)
* Stereo recording to WAV/AIFF/WavPack (lossless) and MP3<ref>MP3, WavPack and AIFF are available on non-Archos devices. Multiple sample rates and bitrates available (hardware-dependent).</ref><ref>{{cite web|title=Recording|url=http://download.rockbox.org/daily/manual/rockbox-sansaclipplus/rockbox-buildch10.html#x13-14900010|work=Rockbox Manual|accessdate=22 May 2011}}</ref> (supporting devices)
* [[FM broadcasting|FM radio]], including FM recording (supporting devices)
* Remote control (supporting devices)
* Digital [[S/PDIF]] input/output (supporting devices)
* [[Last.fm]] support (even on players lacking [[Real-time clock|RTC]])
* [[cue sheet (computing)|Cue sheet]] support
* Changeable selector bar
* Album art<ref>{{cite web|url=http://www.rockbox.org/twiki/bin/view/Main/AlbumArt |title=Some limitations. Details at Rockbox Wiki |publisher=Rockbox.org |date= |accessdate=2011-03-12}}</ref>
* Sleep timer

== External links ==
* [http://www.rockbox.org/ The Rockbox Project]

''~ Text taken from [http://en.wikipedia.org/wiki/Rockbox Wikipedia entry for Rockbox]''

[[Category:Firmware]]

Rockbox

2011-07-19T15:51:15Z

Saratoga: add rockbox codec info

Lossless comparison

2011-07-19T15:49:05Z

Saratoga: /* APE cons */

The '''lossless comparison page''' aims to gather information about lossless codecs available so users can make an informed decision as to what lossless codec to choose for their needs.

== Introduction ==
Given the enormous amount of [[lossless]] audio compressor choices available, it is a very difficult task to choose the one most suited for each person's needs.

Several people only take into consideration compression performance when choosing a codec. But as the following table and article shows, there are several other features worth taking into consideration when making that choice.

For example, users wanting good multiplatform compatibility and robustness (E.G, people sharing live recordings) would favour [[WavPack]] or [[FLAC]]. Another user, looking for the very highest compression available, would go with [[OptimFROG]]. Someone wanting portable support would use [[FLAC]] or [[ALAC]], and so on.

En fin, this is not a matter worth getting too worked up about. If you later find out the codec you chose isn't the best for your needs, you can just transcompress to another format, without risk of losing quality.

'''Note:''' for latest comparison of lossless compression, scroll down to the [[Lossless comparison#External links|Links section of this page]].

== Comparison Table ==


{| cellspacing="2" style="text-align:center; border:1px solid blue;"
|width="120px"|'''Features'''
| width="95px" style="background: #00FFFF" | FLAC
| width="95px" style="background: #00FFFF" | WavPack
| width="95px" style="background: #00FFFF" | TAK
| width="95px" style="background: #00FFFF" | Monkey's
| width="95px" style="background: #00FFFF" | OptimFROG
| width="95px" style="background: #00FFFF" | ALAC
| width="95px" style="background: #00FFFF" | WMA
|-
|align="left" style="background: #FFFF99" | Encoding speed
| style="background: #CCFFCC" | fast
| style="background: #00FF00" | very fast
| style="background: #00FF00" | very fast
| style="background: #CCFFCC" | fast
| style="background: #FF9900" | slow
| style="background: #FFFFFF" | average
| style="background: #FFFFFF" | average
|-
|align="left" style="background: #FFFF99" | Decoding speed
| style="background: #00FF00" | very fast
| style="background: #00FF00" | very fast
| style="background: #00FF00" | very fast
| style="background: #FFFFFF" | average
| style="background: #FFFFFF" | average
| style="background: #CCFFCC" | fast
| style="background: #FFFFFF" | average
|-
|align="left" style="background: #FFFF99" | Compression*
| style="background: #CCFFCC" | 58.70%
| style="background: #CCFFCC" | 58.0%
| style="background: #CCFFCC" | 57.0%
| style="background: #00FF00" | 55.50%
| style="background: #00FF00" | 54.70%
| style="background: #CCFFCC" | 58.50%
| style="background: #00FF00" | 56.30%
|-
|align="left" style="background: #FFFF99" | Flexibility**
| style="background: #00FF00" | very good
| style="background: #00FF00" | very good
| style="background: #00FF00" | very good
| style="background: #00FF00" | very good
| style="background: #00FF00" | very good
| style="background: #FF9900" | bad
| style="background: #FF9900" | bad
|-
|style="background: #FFFFFF" |  
|-
|align="left" style="background: #FFFF99" | Error handling
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #FFFFFF" |  
| style="background: #00FF00" | yes
|-
|align="left" style="background: #FFFF99" | Seeking
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
|-
|align="left" style="background: #FFFF99" | Tagging
| style="background: #00FF00" | Vorbis tags
| style="background: #00FF00" | ID3/APE
| style="background: #CCFFCC" | APEv2 (exp.)
| style="background: #00FF00" | ID3/APE
| style="background: #00FF00" | ID3/APE
| style="background: #CCFFCC" | iTunes
| style="background: #CCFFCC" | ASF
|-
| align="left" style="background: #FFFF99" | Hardware support
| style="background: #00FF00" | very good
| style="background: #FF9900" | limited
| style="background: #FF9900" | no
| style="background: #FF9900" | limited
| style="background: #FF9900" | no
| style="background: #CCFFCC" | good
| style="background: #FF9900" | limited
|-
| align="left" style="background: #FFFF99" | Software support
| style="background: #00FF00" | very good
| style="background: #CCFFCC" | good
| style="background: #FFFFFF" | average
| style="background: #CCFFCC" | good
| style="background: #FFFFFF" | average
| style="background: #FFFFFF" | average
| style="background: #CCFFCC" | good
|-
| align="left" style="background: #FFFF99" | Hybrid/lossy
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #FF9900" | no
|-
| align="left" style="background: #FFFF99" | Replay Gain
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #FFFFFF" | sort of
| style="background: #FF9900" | no
|-
| align="left" style="background: #FFFF99" | RIFF chunks
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #FFFFFF" |  
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #FFFFFF" |  
| style="background: #FF9900" | no
|-
| align="left" style="background: #FFFF99" | Streaming
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
|-
| align="left" style="background: #FFFF99" | Pipe support
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
|-
| align="left" style="background: #FFFF99" | Open source
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #00FF00" | yes (third-party)
| style="background: #FF9900" | no
|-
| align="left" style="background: #FFFF99" | Multichannel
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #FF9900" | no
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
|-
| align="left" style="background: #FFFF99" | High resolution
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
|-
| align="left" style="background: #FFFF99" | OS support
| style="background: #00FF00" | All
| style="background: #00FF00" | All
| style="background: #CCFFCC" | Win/Linux Wine
| style="background: #00FF00" | All
| style="background: #00FF00" | Win/Mac/Linux
| style="background: #00FF00" | All
| style="background: #CCFFCC" | Win/Mac
|}

''(table continued below)''

{| cellspacing="2" style="text-align:center; border:1px solid blue;"
|width="120px"|'''Features'''
| width="95px" style="background: #00FFFF" | Shorten
| width="95px" style="background: #00FFFF" | LA
| width="95px" style="background: #00FFFF" | TTA
| width="95px" style="background: #00FFFF" | LPAC
| width="95px" style="background: #00FFFF" | MPEG-4 ALS
| width="95px" style="background: #00FFFF" | MPEG-4 SLS
| width="95px" style="background: #00FFFF" | Real Lossless
|-
| align="left" style="background: #FFFF99" | Encoding speed
| style="background: #00FF00" | very fast
| style="background: #FF9900" | slow
| style="background: #00FF00" | very fast
| style="background: #FFFFFF" | average
| style="background: #FFFFFF" | average
| style="background: #FF9900" | slow
| style="background: #FF9900" | slow
|-
| align="left" style="background: #FFFF99" | Decoding speed
| style="background: #00FF00" | very fast
| style="background: #FF9900" | slow
| style="background: #CCFFCC" | fast
| style="background: #CCFFCC" | fast
| style="background: #CCFFCC" | fast
| style="background: #FF9900" | slow
| style="background: #CCFFCC" | fast
|-
| align="left" style="background: #FFFF99" | Compression*
| style="background: #FF9900" | 63.50%
| style="background: #00FF00" | 53.50%
| style="background: #CCFFCC" | 57.10%
| style="background: #CCFFCC" | 57.20%
| style="background: #CCFFCC" | 57.10%
| style="background: #CCFFCC" | ?
| style="background: #CCFFCC" | 57.0%
|-
| align="left" style="background: #FFFF99" | Flexibility**
| style="background: #FF9900" | bad
| style="background: #FFFFFF" | average
| style="background: #FF9900" | bad
| style="background: #FF9900" | bad
| style="background: #00FF00" | very good
| style="background: #FF9900" | bad
| style="background: #FF9900" | bad
|-
|! style="background: #FFFFFF" |  
|-
| align="left" style="background: #FFFF99" | Error handling
| style="background: #FF9900" | no
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #FFFFFF" |  
|-
| align="left" style="background: #FFFF99" | Seeking
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #FF9900" | slow
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
|-
| align="left" style="background: #FFFF99" | Tagging
| style="background: #FF9900" | no
| style="background: #CCFFCC" | ID3v1
| style="background: #CCFFCC" | ID3
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #CCFFCC" | proprietary
|-
| align="left" style="background: #FFFF99" | Hardware support
| style="background: #FF9900" | limited
| style="background: #FF9900" | no
| style="background: #FF9900" | limited
| style="background: #FF9900" | no
| style="background: #FF9900" | no
| style="background: #FF9900" | no
| style="background: #FF9900" | no
|-
| align="left" style="background: #FFFF99" | Software support
| style="background: #00FF00" | very good
| style="background: #FF9900" | bad
| style="background: #FFFFFF" | average
| style="background: #FFFFFF" | average
| style="background: #FF9900" | bad
| style="background: #FF9900" | bad
| style="background: #FF9900" | bad
|-
| align="left" style="background: #FFFF99" | Hybrid/lossy
| style="background: #FF9900" | no
| style="background: #FF9900" | no
| style="background: #FF9900" | no
| style="background: #FF9900" | no
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
|-
| align="left" style="background: #FFFF99" | Replay Gain
| style="background: #FF9900" | no
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
|-
| align="left" style="background: #FFFF99" | RIFF chunks
| style="background: #FF9900" | yes
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #FFFFFF" |  
| style="background: #FFFFFF" |  
| style="background: #FFFFFF" |  
|-
| align="left" style="background: #FFFF99" | Streaming
| style="background: #FF9900" | no
| style="background: #FFFFFF" |  
| style="background: #FF9900" | no
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
|-
| align="left" style="background: #FFFF99" | Pipe support
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #FFFFFF" |  
| style="background: #FFFFFF" |  
| style="background: #FFFFFF" |  
| style="background: #FF9900" | no
|-
| align="left" style="background: #FFFF99" | Open source
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
|-
| align="left" style="background: #FFFF99" | Multichannel
| style="background: #FF9900" | no
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
|-
| align="left" style="background: #FFFF99" | High resolution
| style="background: #FF9900" | no
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
|-
| align="left" style="background: #FFFF99" | OS support
| style="background: #00FF00" | All
| style="background: #CCFFCC" | Win/Linux
| style="background: #00FF00" | All
| style="background: #CCFFCC" | Win/Linux/Sol
| style="background: #00FF00" | All
| style="background: #00FF00" | All
| style="background: #00FF00" | Win/Mac/Linux
|}

<nowiki>*</nowiki> The Compression ratio is calculated with the division of compressed size by uncompressed size * 100. So, lower is better.

Encoding speed, Decoding speed and Compression ratio are based on each encoder's default settings.

<nowiki>**</nowiki> Flexibility refers to the amount of encoding choices offered to the users (Fast/low compression, Slow/high compression and everything inbetween)

These are the most popular lossless codecs, in alphabetical order:

== Apple Lossless Audio Codec (ALAC) ==
http://www.apple.com/itunes/import.html

[[ALAC]] is a codec developed by Apple for usage in [[Apple iPod|iPod]] and AirPort Express.

=== ALAC pros ===
* Very fast decoding
* [[Open source]] (encoding and decoding via FFmpeg and [[CueTools|CUETools]], decoding only via [http://craz.net/programs/itunes/alac.html a standalone decoder])
* Hardware support ([[Apple iPod|iPod]], AirPort Express)
* Streaming support
* Tagging support (QT tags)
* Excellent hardware-software-lossy format integration with [[iTunes]]/iPod.
* Supports [[multichannel]] audio and [[high resolution]]s

=== ALAC cons ===
* Limited software support
* No hybrid/lossy mode

=== ALAC Other features ===
* Fits in the [[MP4]] container
* Can be used with the AirPort Express gadget

== Free Lossless Audio Codec (FLAC) ==
http://flac.sourceforge.net/

[[FLAC]] is a lossless codec developed by Josh Coalson. It's part of the Xiph multimedia portfolio, along with [[Ogg]], [[Vorbis]], [[Speex]] and [[Theora]].

=== FLAC pros ===
* [[Open source]]
* Very fast decoding
* Fast encoding
* Hardware support ([[Rio Karma|Karma]], Phatbox, etc.)
* Very good software support
* Error robustness
* Streaming support
* Supports [[multichannel]] audio and [[high resolution]]s
* Tagging support (FLAC tags)
* Supports [[RIFF]] chunks
* Pipe support
* [[Replay Gain]] compatible

=== FLAC cons ===
* No hybrid/lossy mode

=== FLAC Other features ===
* Supports embedded CUE sheets (with [http://flac.sourceforge.net/faq.html#general__no_cuesheet_tags limitations])
* Includes MD5 hashes for quick integrity checking
* Fits the [[Ogg]] and [[Matroska]] containers

== LosslessAudio (LA) ==
http://www.lossless-audio.com/

[[LA]] is a lossless codec developed by Michael Bevin.

=== LA pros ===
* Very high compression
* Tagging support ([[ID3v1]])
* Supports [[RIFF]] chunks
* Pipe support

=== LA cons ===
* Closed source
* Very slow encoding and decoding
* Doesn't support [[multichannel]] audio and [[high resolution]]s
* No hardware support
* No hybrid/lossy mode
* Bad software support
* Doesn't support [[Replay Gain]]

'''''It's important to mention that the LA foobar plugin is buggy and doesn't produce lossless streams!'''''

== Lossless Predictive Audio Coder (LPAC) ==
http://www.nue.tu-berlin.de/wer/liebchen/lpac.html

[[Lossless Predictive Audio Coder]] (LPAC) is a lossless codec developed by Tilman Liebchen. Development of it has been halted in favour of development of [[MPEG-4]] ALS.

=== LPAC pros ===
* Reasonable compression ratios
* [[High resolution]] audio support
* Supports [[RIFF]] chunks

=== LPAC cons ===
* Closed source
* No error robustness
* Slow seeking
* No tagging
* No [[multichannel]] support
* No hybrid/lossy mode
* No hardware support
* Doesn't support [[Replay Gain]]

== Monkey's Audio (APE) ==
http://www.monkeysaudio.com/

[[Monkey's Audio]] is a very efficient lossless compressor developed by Matt Ashland.

=== APE pros ===
* [[Open source]]
* High efficiency
* Good software support
* Simple and user friendly. Official GUI provided.
* Java version (multiplatform)
* Tagging support ([[ID3v1]], [[APE tags]])
* [[High resolution]] audio support
* Supports [[RIFF]] chunks (only in the GUI encoder)
* Pipe support (only in a [http://www.etree.org/shnutils/shntool/ special] version)

=== APE cons ===
* No [[multichannel]] support
* No error robustness
* No hybrid/lossy mode
* Limited hardware support (Rockbox, some Cowon players); poor battery life due to complicated decoding [http://www.rockbox.org/wiki/SoundCodecMonkeysAudio MP3 player benchmarks]
* Higher compression levels are extremely CPU intensive
* Doesn't support [[Replay Gain]]

=== APE Other features ===
* Includes MD5 hashes for quick integrity checking
* Supports APL image link files (similar to CUE sheets)

== MPEG-4 SLS ==
MPEG-4 SLS allows audio encoding from lossless scalable to [[AAC]].

=== SLS pros ===
* Transcoding to standard AAC or any higher lossy bitrate at the speed of copying a file
* Scalable decoding from lossless, to any bitrate down to the AAC core track
* Best lossless compression available when you count the AAC track (~5% gain over any other lossless compression + AAC)
* [[High resolution]] audio support
* Multi channel audio support
* [[Open source]] (MPEG-4 Reference code)
* Embedded in standard MP4 files, so supports same tagging and Replay Gain features as AAC does.

=== SLS cons ===
* No usable software available yet
* Pure lossless compression not the best there is
* Seems to be slow in encoding and decoding, but we have to wait for released software

=== SLS Other features ===
* Transform based lossless codec with optional LC AAC core track

== OptimFROG (OFR) ==
http://losslessaudiocompression.com/

[[OptimFROG]] is a lossless format developed by Florin Ghido to become the champion in audio compression.

=== OFR pros ===
* Very high compression
* Good software support
* Error robustness
* Streaming support
* Supports [[high resolution]]s
* Hybrid/lossy mode
* Tagging support ([[ID3]], [[APE tags]])
* Supports [[RIFF]] chunks
* [[Replay Gain]] compatible

=== OFR cons ===
* Closed source
* No [[multichannel]] audio support
* No hardware support
* Quite slow decoding

=== OFR Other features ===
* Supports 32bit float streams
* Includes MD5 hashes for quick integrity checking

== RealAudio Lossless (RAL) ==
http://www.realnetworks.com/products/codecs/realaudio.html

RealAudio lossless is the lossless codec developed by Real Networks for their multimedia portfolio

=== RAL pros ===
* Very fast decoding
* Streaming support
* Tagging support (proprietary)

=== RAL cons ===
* Closed source
* No [[multichannel]] and [[high resolution]] audio support
* Little software support (Real Player)
* No hardware support
* Compression efficiency not on par with other lossless codecs
* No hybrid/lossy mode
* No pipe support
* Doesn't support [[Replay Gain]]

== Shorten (SHN) ==
http://www.etree.org/shnutils/shorten/

[[Shorten]] is a very old and featureless lossless codec developed by Tony Robinson at SoftSound.

=== SHN pros ===
* [[Open source]]
* Fast decoding
* Very good software support
* Supports [[RIFF]] chunks
* Pipe support

=== SHN cons ===
* Quite inefficient
* No [[multichannel]] or [[high resolution]] audio support
* No hybrid/lossy mode
* No error robustness
* Not streamable
* No hardware support
* No native tagging
* Doesn't support [[Replay Gain]]

== True Audio (TTA) ==
http://www.true-audio.com/

[[TTA]] is a new lossless codec developed by a team of russian programmers.

=== TTA pros ===
* [[Open source]]
* Good efficiency
* Hardware support (obscure DVD player)
* Supports [[multichannel]] audio and [[high resolution]]s
* Tagging support ([[ID3]])
* [[Replay Gain]] compatible
* Error robustness

=== TTA cons ===
* No streaming support
* No hybrid/lossy mode
* Doesn't support [[RIFF]] chunks
* No pipe support

=== TTA Other features ===
* Fits the [[Matroska]] container

== WavPack (WV) ==
http://www.wavpack.com/

[[WavPack]] is a fast and featureful lossless codec developed by David Bryant.

=== WV pros ===
* [[Open source]]
* Very fast decoding
* Very fast encoding
* Good efficiency
* Error robustness
* Streaming support
* Hardware support ([http://www.rockbox.org/ RockBox])
* Supports [[multichannel]] audio and [[high resolution]]s
* Hybrid/lossy mode
* Tagging support ([[ID3v1]], [[APE tags]])
* Supports [[RIFF]] chunks
* Ability to create self extracting files for Win32 platform
* Pipe support
* Good software support
* [[Replay Gain]] compatible

=== WV cons ===
* Limited hardware player support

=== WV Other features ===
* Supports 32bit float streams
* Supports embedded CUE sheets
* Includes MD5 hashes for quick integrity checking
* Can encode in both symmetrical and assymmetrical modes.
* Fits the [[Matroska]] container

== Windows Media Audio Lossless (WMAL) ==
http://www.microsoft.com/windows/windowsmedia/9series/codecs/audio.aspx

WMA Lossless is the lossless codec developed by Microsoft to be featured in their Windows Media codec portfolio.

=== WMAL pros ===
* Streaming support
* Very good software support
* Hardware support (All Microsoft Zunes though older models may need firmware updates, also supported by some non-Microsoft devices like the [http://en.wikipedia.org/wiki/Gigabeat Gigabeat V and S line from Toshiba].
* Supports [[multichannel]] audio and [[high resolution]]s.
* Tagging support (proprietary)
* Pipe support

=== WMAL cons ===
* Closed source
* No hybrid/lossy mode
* Doesn't support [[RIFF]] chunks
* Doesn't support [[Replay Gain]]

=== WMAL Other features ===
* Fits the [[ASF]] container

== Oddball Formats ==
There are several old lossless formats that aren't being featured in the article above. Reasons are: lack of widespread support, lack of features, bad efficiency and, most importantly, it seems no one is really interested in them.

Most of those would have disappeared by now, but they are being preserved for posterity at [[User:Rjamorim|rjamorim]]'s [http://www.rjamorim.com/rrw/ ReallyRareWares]

=== Advanced Digital Audio (ADA) ===
* http://www.rjamorim.com/rrw/ada.html

=== Bonk ===
* http://www.logarithmic.net/pfh/bonk

=== Marian's a-Pac ===
* http://www.marian.de/en/downloads#APAC
* http://www.rjamorim.com/rrw/apac.html

=== AudioZip ===
* http://www.rjamorim.com/rrw/audiozip.html

=== Dakx WAV ===
* http://www.dakx.com/
* http://www.rjamorim.com/rrw/daxwav.html

=== Entis Lab MIO ===
* http://www.entis.gr.jp/eri/frame.html
* http://www.rjamorim.com/rrw/mio.html

=== LiteWave ===
* http://www.clearjump.com/products/LiteWave.html
* http://www.rjamorim.com/rrw/litewave.html

=== Pegasus SPS ===
* http://www.krishnasoft.com/sps.htm
* http://www.rjamorim.com/rrw/pegasussps.html

=== RK Audio (RKAU) ===
* http://www.rjamorim.com/rrw/split2000.html

=== Sonarc ===
* http://www.rjamorim.com/rrw/sonarc.html

=== VocPack ===
* http://www.rjamorim.com/rrw/vocpack.html

=== WavArc ===
* http://www.rjamorim.com/rrw/wavarc.html

=== WaveZip/MUSICompress ===
* http://members.aol.com/_ht_a/sndspace/
* http://www.rjamorim.com/rrw/wavezip.html

== See also ==
* [[Lossless]]

== External links ==
=== Other lossless compressions comparisons ===
''Sorted based on last '''update''' date.''

* [http://uclc.info/LossLess.pdf Johan De Bock's speed oriented comparison] - best choices speedwise are indicated in green, mostly electronic music (last updated 2006-07-22)
* [http://web.inter.nl.net/users/hvdh/lossless/lossless.htm Hans Heijden's] -- used as reference to build the table (last updated 2006-07-07)
* [http://synthetic-soul.co.uk/comparison/lossless/ Synthetic Soul's comparison] (last update 2007-07-28)
* [http://synthetic-soul.co.uk/comparison/josef/ Josef Pohm's comparison, hosted by Synthetic Soul] (last update 2006-05-29)
* [http://www.bobulous.org.uk/misc/lossless_audio_2006.html Bobulous' lossless audio comparison] — a look at six lossless formats in terms of speed and file size (last updated 2006-05-22)
* [http://uclc.info/lossless_audio_compression_test.htm Johan De Bock's size oriented comparison] - aimed only at the maximum compression setting for each codec (based on a somewhat limited set of samples, however) (last updated 2006-05-19)
* [http://guruboolez.free.fr/lossless/ Guruboolez'] -- comparing only classical music (last updated 2005-02-27)
* [http://members.home.nl/w.speek/comparison.htm Speek's] (last updated 2005-02-07)

=== More on lossless compressions ===
* [http://losslessaudioblog.com/ The Lossless Audio Blog] - by windmiller, is a reliable and complete source of news about lossless compression.
* Go to the [http://www.hydrogenaudio.org/forums/index.php?showtopic=33226 Hydrogenaudio thread] to discuss this article.

[[Category:Guides]]

Rockbox

2011-07-19T15:46:55Z

Saratoga: Remove badly out of date rockbox device information

Lossless comparison

2011-07-19T15:44:04Z

Saratoga: /* Monkey's Audio (APE) */ Update APE hardware support, mention that its really hard to decode on ARM devices

The '''lossless comparison page''' aims to gather information about lossless codecs available so users can make an informed decision as to what lossless codec to choose for their needs.

== Introduction ==
Given the enormous amount of [[lossless]] audio compressor choices available, it is a very difficult task to choose the one most suited for each person's needs.

Several people only take into consideration compression performance when choosing a codec. But as the following table and article shows, there are several other features worth taking into consideration when making that choice.

For example, users wanting good multiplatform compatibility and robustness (E.G, people sharing live recordings) would favour [[WavPack]] or [[FLAC]]. Another user, looking for the very highest compression available, would go with [[OptimFROG]]. Someone wanting portable support would use [[FLAC]] or [[ALAC]], and so on.

En fin, this is not a matter worth getting too worked up about. If you later find out the codec you chose isn't the best for your needs, you can just transcompress to another format, without risk of losing quality.

'''Note:''' for latest comparison of lossless compression, scroll down to the [[Lossless comparison#External links|Links section of this page]].

== Comparison Table ==


{| cellspacing="2" style="text-align:center; border:1px solid blue;"
|width="120px"|'''Features'''
| width="95px" style="background: #00FFFF" | FLAC
| width="95px" style="background: #00FFFF" | WavPack
| width="95px" style="background: #00FFFF" | TAK
| width="95px" style="background: #00FFFF" | Monkey's
| width="95px" style="background: #00FFFF" | OptimFROG
| width="95px" style="background: #00FFFF" | ALAC
| width="95px" style="background: #00FFFF" | WMA
|-
|align="left" style="background: #FFFF99" | Encoding speed
| style="background: #CCFFCC" | fast
| style="background: #00FF00" | very fast
| style="background: #00FF00" | very fast
| style="background: #CCFFCC" | fast
| style="background: #FF9900" | slow
| style="background: #FFFFFF" | average
| style="background: #FFFFFF" | average
|-
|align="left" style="background: #FFFF99" | Decoding speed
| style="background: #00FF00" | very fast
| style="background: #00FF00" | very fast
| style="background: #00FF00" | very fast
| style="background: #FFFFFF" | average
| style="background: #FFFFFF" | average
| style="background: #CCFFCC" | fast
| style="background: #FFFFFF" | average
|-
|align="left" style="background: #FFFF99" | Compression*
| style="background: #CCFFCC" | 58.70%
| style="background: #CCFFCC" | 58.0%
| style="background: #CCFFCC" | 57.0%
| style="background: #00FF00" | 55.50%
| style="background: #00FF00" | 54.70%
| style="background: #CCFFCC" | 58.50%
| style="background: #00FF00" | 56.30%
|-
|align="left" style="background: #FFFF99" | Flexibility**
| style="background: #00FF00" | very good
| style="background: #00FF00" | very good
| style="background: #00FF00" | very good
| style="background: #00FF00" | very good
| style="background: #00FF00" | very good
| style="background: #FF9900" | bad
| style="background: #FF9900" | bad
|-
|style="background: #FFFFFF" |  
|-
|align="left" style="background: #FFFF99" | Error handling
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #FFFFFF" |  
| style="background: #00FF00" | yes
|-
|align="left" style="background: #FFFF99" | Seeking
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
|-
|align="left" style="background: #FFFF99" | Tagging
| style="background: #00FF00" | Vorbis tags
| style="background: #00FF00" | ID3/APE
| style="background: #CCFFCC" | APEv2 (exp.)
| style="background: #00FF00" | ID3/APE
| style="background: #00FF00" | ID3/APE
| style="background: #CCFFCC" | iTunes
| style="background: #CCFFCC" | ASF
|-
| align="left" style="background: #FFFF99" | Hardware support
| style="background: #00FF00" | very good
| style="background: #FF9900" | limited
| style="background: #FF9900" | no
| style="background: #FF9900" | limited
| style="background: #FF9900" | no
| style="background: #CCFFCC" | good
| style="background: #FF9900" | limited
|-
| align="left" style="background: #FFFF99" | Software support
| style="background: #00FF00" | very good
| style="background: #CCFFCC" | good
| style="background: #FFFFFF" | average
| style="background: #CCFFCC" | good
| style="background: #FFFFFF" | average
| style="background: #FFFFFF" | average
| style="background: #CCFFCC" | good
|-
| align="left" style="background: #FFFF99" | Hybrid/lossy
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #FF9900" | no
|-
| align="left" style="background: #FFFF99" | Replay Gain
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #FFFFFF" | sort of
| style="background: #FF9900" | no
|-
| align="left" style="background: #FFFF99" | RIFF chunks
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #FFFFFF" |  
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #FFFFFF" |  
| style="background: #FF9900" | no
|-
| align="left" style="background: #FFFF99" | Streaming
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
|-
| align="left" style="background: #FFFF99" | Pipe support
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
|-
| align="left" style="background: #FFFF99" | Open source
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #00FF00" | yes (third-party)
| style="background: #FF9900" | no
|-
| align="left" style="background: #FFFF99" | Multichannel
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #FF9900" | no
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
|-
| align="left" style="background: #FFFF99" | High resolution
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
|-
| align="left" style="background: #FFFF99" | OS support
| style="background: #00FF00" | All
| style="background: #00FF00" | All
| style="background: #CCFFCC" | Win/Linux Wine
| style="background: #00FF00" | All
| style="background: #00FF00" | Win/Mac/Linux
| style="background: #00FF00" | All
| style="background: #CCFFCC" | Win/Mac
|}

''(table continued below)''

{| cellspacing="2" style="text-align:center; border:1px solid blue;"
|width="120px"|'''Features'''
| width="95px" style="background: #00FFFF" | Shorten
| width="95px" style="background: #00FFFF" | LA
| width="95px" style="background: #00FFFF" | TTA
| width="95px" style="background: #00FFFF" | LPAC
| width="95px" style="background: #00FFFF" | MPEG-4 ALS
| width="95px" style="background: #00FFFF" | MPEG-4 SLS
| width="95px" style="background: #00FFFF" | Real Lossless
|-
| align="left" style="background: #FFFF99" | Encoding speed
| style="background: #00FF00" | very fast
| style="background: #FF9900" | slow
| style="background: #00FF00" | very fast
| style="background: #FFFFFF" | average
| style="background: #FFFFFF" | average
| style="background: #FF9900" | slow
| style="background: #FF9900" | slow
|-
| align="left" style="background: #FFFF99" | Decoding speed
| style="background: #00FF00" | very fast
| style="background: #FF9900" | slow
| style="background: #CCFFCC" | fast
| style="background: #CCFFCC" | fast
| style="background: #CCFFCC" | fast
| style="background: #FF9900" | slow
| style="background: #CCFFCC" | fast
|-
| align="left" style="background: #FFFF99" | Compression*
| style="background: #FF9900" | 63.50%
| style="background: #00FF00" | 53.50%
| style="background: #CCFFCC" | 57.10%
| style="background: #CCFFCC" | 57.20%
| style="background: #CCFFCC" | 57.10%
| style="background: #CCFFCC" | ?
| style="background: #CCFFCC" | 57.0%
|-
| align="left" style="background: #FFFF99" | Flexibility**
| style="background: #FF9900" | bad
| style="background: #FFFFFF" | average
| style="background: #FF9900" | bad
| style="background: #FF9900" | bad
| style="background: #00FF00" | very good
| style="background: #FF9900" | bad
| style="background: #FF9900" | bad
|-
|! style="background: #FFFFFF" |  
|-
| align="left" style="background: #FFFF99" | Error handling
| style="background: #FF9900" | no
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #FFFFFF" |  
|-
| align="left" style="background: #FFFF99" | Seeking
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #FF9900" | slow
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
|-
| align="left" style="background: #FFFF99" | Tagging
| style="background: #FF9900" | no
| style="background: #CCFFCC" | ID3v1
| style="background: #CCFFCC" | ID3
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #CCFFCC" | proprietary
|-
| align="left" style="background: #FFFF99" | Hardware support
| style="background: #FF9900" | limited
| style="background: #FF9900" | no
| style="background: #FF9900" | limited
| style="background: #FF9900" | no
| style="background: #FF9900" | no
| style="background: #FF9900" | no
| style="background: #FF9900" | no
|-
| align="left" style="background: #FFFF99" | Software support
| style="background: #00FF00" | very good
| style="background: #FF9900" | bad
| style="background: #FFFFFF" | average
| style="background: #FFFFFF" | average
| style="background: #FF9900" | bad
| style="background: #FF9900" | bad
| style="background: #FF9900" | bad
|-
| align="left" style="background: #FFFF99" | Hybrid/lossy
| style="background: #FF9900" | no
| style="background: #FF9900" | no
| style="background: #FF9900" | no
| style="background: #FF9900" | no
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
|-
| align="left" style="background: #FFFF99" | Replay Gain
| style="background: #FF9900" | no
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
|-
| align="left" style="background: #FFFF99" | RIFF chunks
| style="background: #FF9900" | yes
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #FFFFFF" |  
| style="background: #FFFFFF" |  
| style="background: #FFFFFF" |  
|-
| align="left" style="background: #FFFF99" | Streaming
| style="background: #FF9900" | no
| style="background: #FFFFFF" |  
| style="background: #FF9900" | no
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
|-
| align="left" style="background: #FFFF99" | Pipe support
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #FFFFFF" |  
| style="background: #FFFFFF" |  
| style="background: #FFFFFF" |  
| style="background: #FF9900" | no
|-
| align="left" style="background: #FFFF99" | Open source
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
|-
| align="left" style="background: #FFFF99" | Multichannel
| style="background: #FF9900" | no
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
|-
| align="left" style="background: #FFFF99" | High resolution
| style="background: #FF9900" | no
| style="background: #FF9900" | no
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #00FF00" | yes
| style="background: #FF9900" | no
|-
| align="left" style="background: #FFFF99" | OS support
| style="background: #00FF00" | All
| style="background: #CCFFCC" | Win/Linux
| style="background: #00FF00" | All
| style="background: #CCFFCC" | Win/Linux/Sol
| style="background: #00FF00" | All
| style="background: #00FF00" | All
| style="background: #00FF00" | Win/Mac/Linux
|}

<nowiki>*</nowiki> The Compression ratio is calculated with the division of compressed size by uncompressed size * 100. So, lower is better.

Encoding speed, Decoding speed and Compression ratio are based on each encoder's default settings.

<nowiki>**</nowiki> Flexibility refers to the amount of encoding choices offered to the users (Fast/low compression, Slow/high compression and everything inbetween)

These are the most popular lossless codecs, in alphabetical order:

== Apple Lossless Audio Codec (ALAC) ==
http://www.apple.com/itunes/import.html

[[ALAC]] is a codec developed by Apple for usage in [[Apple iPod|iPod]] and AirPort Express.

=== ALAC pros ===
* Very fast decoding
* [[Open source]] (encoding and decoding via FFmpeg and [[CueTools|CUETools]], decoding only via [http://craz.net/programs/itunes/alac.html a standalone decoder])
* Hardware support ([[Apple iPod|iPod]], AirPort Express)
* Streaming support
* Tagging support (QT tags)
* Excellent hardware-software-lossy format integration with [[iTunes]]/iPod.
* Supports [[multichannel]] audio and [[high resolution]]s

=== ALAC cons ===
* Limited software support
* No hybrid/lossy mode

=== ALAC Other features ===
* Fits in the [[MP4]] container
* Can be used with the AirPort Express gadget

== Free Lossless Audio Codec (FLAC) ==
http://flac.sourceforge.net/

[[FLAC]] is a lossless codec developed by Josh Coalson. It's part of the Xiph multimedia portfolio, along with [[Ogg]], [[Vorbis]], [[Speex]] and [[Theora]].

=== FLAC pros ===
* [[Open source]]
* Very fast decoding
* Fast encoding
* Hardware support ([[Rio Karma|Karma]], Phatbox, etc.)
* Very good software support
* Error robustness
* Streaming support
* Supports [[multichannel]] audio and [[high resolution]]s
* Tagging support (FLAC tags)
* Supports [[RIFF]] chunks
* Pipe support
* [[Replay Gain]] compatible

=== FLAC cons ===
* No hybrid/lossy mode

=== FLAC Other features ===
* Supports embedded CUE sheets (with [http://flac.sourceforge.net/faq.html#general__no_cuesheet_tags limitations])
* Includes MD5 hashes for quick integrity checking
* Fits the [[Ogg]] and [[Matroska]] containers

== LosslessAudio (LA) ==
http://www.lossless-audio.com/

[[LA]] is a lossless codec developed by Michael Bevin.

=== LA pros ===
* Very high compression
* Tagging support ([[ID3v1]])
* Supports [[RIFF]] chunks
* Pipe support

=== LA cons ===
* Closed source
* Very slow encoding and decoding
* Doesn't support [[multichannel]] audio and [[high resolution]]s
* No hardware support
* No hybrid/lossy mode
* Bad software support
* Doesn't support [[Replay Gain]]

'''''It's important to mention that the LA foobar plugin is buggy and doesn't produce lossless streams!'''''

== Lossless Predictive Audio Coder (LPAC) ==
http://www.nue.tu-berlin.de/wer/liebchen/lpac.html

[[Lossless Predictive Audio Coder]] (LPAC) is a lossless codec developed by Tilman Liebchen. Development of it has been halted in favour of development of [[MPEG-4]] ALS.

=== LPAC pros ===
* Reasonable compression ratios
* [[High resolution]] audio support
* Supports [[RIFF]] chunks

=== LPAC cons ===
* Closed source
* No error robustness
* Slow seeking
* No tagging
* No [[multichannel]] support
* No hybrid/lossy mode
* No hardware support
* Doesn't support [[Replay Gain]]

== Monkey's Audio (APE) ==
http://www.monkeysaudio.com/

[[Monkey's Audio]] is a very efficient lossless compressor developed by Matt Ashland.

=== APE pros ===
* [[Open source]]
* High efficiency
* Good software support
* Simple and user friendly. Official GUI provided.
* Java version (multiplatform)
* Tagging support ([[ID3v1]], [[APE tags]])
* [[High resolution]] audio support
* Supports [[RIFF]] chunks (only in the GUI encoder)
* Pipe support (only in a [http://www.etree.org/shnutils/shntool/ special] version)

=== APE cons ===
* No [[multichannel]] support
* No error robustness
* No hybrid/lossy mode
* Limited hardware support (Rockbox, some Cowon players); poor battery life due to complicated decoding
* Higher compression levels are extremely CPU intensive
* Doesn't support [[Replay Gain]]

=== APE Other features ===
* Includes MD5 hashes for quick integrity checking
* Supports APL image link files (similar to CUE sheets)

== MPEG-4 SLS ==
MPEG-4 SLS allows audio encoding from lossless scalable to [[AAC]].

=== SLS pros ===
* Transcoding to standard AAC or any higher lossy bitrate at the speed of copying a file
* Scalable decoding from lossless, to any bitrate down to the AAC core track
* Best lossless compression available when you count the AAC track (~5% gain over any other lossless compression + AAC)
* [[High resolution]] audio support
* Multi channel audio support
* [[Open source]] (MPEG-4 Reference code)
* Embedded in standard MP4 files, so supports same tagging and Replay Gain features as AAC does.

=== SLS cons ===
* No usable software available yet
* Pure lossless compression not the best there is
* Seems to be slow in encoding and decoding, but we have to wait for released software

=== SLS Other features ===
* Transform based lossless codec with optional LC AAC core track

== OptimFROG (OFR) ==
http://losslessaudiocompression.com/

[[OptimFROG]] is a lossless format developed by Florin Ghido to become the champion in audio compression.

=== OFR pros ===
* Very high compression
* Good software support
* Error robustness
* Streaming support
* Supports [[high resolution]]s
* Hybrid/lossy mode
* Tagging support ([[ID3]], [[APE tags]])
* Supports [[RIFF]] chunks
* [[Replay Gain]] compatible

=== OFR cons ===
* Closed source
* No [[multichannel]] audio support
* No hardware support
* Quite slow decoding

=== OFR Other features ===
* Supports 32bit float streams
* Includes MD5 hashes for quick integrity checking

== RealAudio Lossless (RAL) ==
http://www.realnetworks.com/products/codecs/realaudio.html

RealAudio lossless is the lossless codec developed by Real Networks for their multimedia portfolio

=== RAL pros ===
* Very fast decoding
* Streaming support
* Tagging support (proprietary)

=== RAL cons ===
* Closed source
* No [[multichannel]] and [[high resolution]] audio support
* Little software support (Real Player)
* No hardware support
* Compression efficiency not on par with other lossless codecs
* No hybrid/lossy mode
* No pipe support
* Doesn't support [[Replay Gain]]

== Shorten (SHN) ==
http://www.etree.org/shnutils/shorten/

[[Shorten]] is a very old and featureless lossless codec developed by Tony Robinson at SoftSound.

=== SHN pros ===
* [[Open source]]
* Fast decoding
* Very good software support
* Supports [[RIFF]] chunks
* Pipe support

=== SHN cons ===
* Quite inefficient
* No [[multichannel]] or [[high resolution]] audio support
* No hybrid/lossy mode
* No error robustness
* Not streamable
* No hardware support
* No native tagging
* Doesn't support [[Replay Gain]]

== True Audio (TTA) ==
http://www.true-audio.com/

[[TTA]] is a new lossless codec developed by a team of russian programmers.

=== TTA pros ===
* [[Open source]]
* Good efficiency
* Hardware support (obscure DVD player)
* Supports [[multichannel]] audio and [[high resolution]]s
* Tagging support ([[ID3]])
* [[Replay Gain]] compatible
* Error robustness

=== TTA cons ===
* No streaming support
* No hybrid/lossy mode
* Doesn't support [[RIFF]] chunks
* No pipe support

=== TTA Other features ===
* Fits the [[Matroska]] container

== WavPack (WV) ==
http://www.wavpack.com/

[[WavPack]] is a fast and featureful lossless codec developed by David Bryant.

=== WV pros ===
* [[Open source]]
* Very fast decoding
* Very fast encoding
* Good efficiency
* Error robustness
* Streaming support
* Hardware support ([http://www.rockbox.org/ RockBox])
* Supports [[multichannel]] audio and [[high resolution]]s
* Hybrid/lossy mode
* Tagging support ([[ID3v1]], [[APE tags]])
* Supports [[RIFF]] chunks
* Ability to create self extracting files for Win32 platform
* Pipe support
* Good software support
* [[Replay Gain]] compatible

=== WV cons ===
* Limited hardware player support

=== WV Other features ===
* Supports 32bit float streams
* Supports embedded CUE sheets
* Includes MD5 hashes for quick integrity checking
* Can encode in both symmetrical and assymmetrical modes.
* Fits the [[Matroska]] container

== Windows Media Audio Lossless (WMAL) ==
http://www.microsoft.com/windows/windowsmedia/9series/codecs/audio.aspx

WMA Lossless is the lossless codec developed by Microsoft to be featured in their Windows Media codec portfolio.

=== WMAL pros ===
* Streaming support
* Very good software support
* Hardware support (All Microsoft Zunes though older models may need firmware updates, also supported by some non-Microsoft devices like the [http://en.wikipedia.org/wiki/Gigabeat Gigabeat V and S line from Toshiba].
* Supports [[multichannel]] audio and [[high resolution]]s.
* Tagging support (proprietary)
* Pipe support

=== WMAL cons ===
* Closed source
* No hybrid/lossy mode
* Doesn't support [[RIFF]] chunks
* Doesn't support [[Replay Gain]]

=== WMAL Other features ===
* Fits the [[ASF]] container

== Oddball Formats ==
There are several old lossless formats that aren't being featured in the article above. Reasons are: lack of widespread support, lack of features, bad efficiency and, most importantly, it seems no one is really interested in them.

Most of those would have disappeared by now, but they are being preserved for posterity at [[User:Rjamorim|rjamorim]]'s [http://www.rjamorim.com/rrw/ ReallyRareWares]

=== Advanced Digital Audio (ADA) ===
* http://www.rjamorim.com/rrw/ada.html

=== Bonk ===
* http://www.logarithmic.net/pfh/bonk

=== Marian's a-Pac ===
* http://www.marian.de/en/downloads#APAC
* http://www.rjamorim.com/rrw/apac.html

=== AudioZip ===
* http://www.rjamorim.com/rrw/audiozip.html

=== Dakx WAV ===
* http://www.dakx.com/
* http://www.rjamorim.com/rrw/daxwav.html

=== Entis Lab MIO ===
* http://www.entis.gr.jp/eri/frame.html
* http://www.rjamorim.com/rrw/mio.html

=== LiteWave ===
* http://www.clearjump.com/products/LiteWave.html
* http://www.rjamorim.com/rrw/litewave.html

=== Pegasus SPS ===
* http://www.krishnasoft.com/sps.htm
* http://www.rjamorim.com/rrw/pegasussps.html

=== RK Audio (RKAU) ===
* http://www.rjamorim.com/rrw/split2000.html

=== Sonarc ===
* http://www.rjamorim.com/rrw/sonarc.html

=== VocPack ===
* http://www.rjamorim.com/rrw/vocpack.html

=== WavArc ===
* http://www.rjamorim.com/rrw/wavarc.html

=== WaveZip/MUSICompress ===
* http://members.aol.com/_ht_a/sndspace/
* http://www.rjamorim.com/rrw/wavezip.html

== See also ==
* [[Lossless]]

== External links ==
=== Other lossless compressions comparisons ===
''Sorted based on last '''update''' date.''

* [http://uclc.info/LossLess.pdf Johan De Bock's speed oriented comparison] - best choices speedwise are indicated in green, mostly electronic music (last updated 2006-07-22)
* [http://web.inter.nl.net/users/hvdh/lossless/lossless.htm Hans Heijden's] -- used as reference to build the table (last updated 2006-07-07)
* [http://synthetic-soul.co.uk/comparison/lossless/ Synthetic Soul's comparison] (last update 2007-07-28)
* [http://synthetic-soul.co.uk/comparison/josef/ Josef Pohm's comparison, hosted by Synthetic Soul] (last update 2006-05-29)
* [http://www.bobulous.org.uk/misc/lossless_audio_2006.html Bobulous' lossless audio comparison] — a look at six lossless formats in terms of speed and file size (last updated 2006-05-22)
* [http://uclc.info/lossless_audio_compression_test.htm Johan De Bock's size oriented comparison] - aimed only at the maximum compression setting for each codec (based on a somewhat limited set of samples, however) (last updated 2006-05-19)
* [http://guruboolez.free.fr/lossless/ Guruboolez'] -- comparing only classical music (last updated 2005-02-27)
* [http://members.home.nl/w.speek/comparison.htm Speek's] (last updated 2005-02-07)

=== More on lossless compressions ===
* [http://losslessaudioblog.com/ The Lossless Audio Blog] - by windmiller, is a reliable and complete source of news about lossless compression.
* Go to the [http://www.hydrogenaudio.org/forums/index.php?showtopic=33226 Hydrogenaudio thread] to discuss this article.

[[Category:Guides]]