Hydrogenaudio Knowledgebase - User contributions [en]

Talk:Hydrogenaudio Listening Tests

2024-03-05T05:18:32Z

Jensend: no personal listening tests here please, there's a separate page for that

2006-02-28 Norz: added guruboolez' 96kbps test, no time to detail versions of encoders used. If someone feels like adding this info, please feel free!

I removed a guruboolez test; this is not the page for personal listening tests. Put those on the [[Private Listening Tests]] page. [[User:Jensend|Jensend]] ([[User talk:Jensend|talk]]) 05:18, 5 March 2024 (UTC)

Hydrogenaudio Listening Tests

2024-03-05T05:18:16Z

Jensend: Undo revision 35480 by 208.127.232.205 (talk) That's a private listening test

One of the most visible ways that HydrogenAudio members have shown their enthusiasm for audio quality and their respect for [[TOS 8|scientific principles]] over the years is by organizing and participating in public blind listening tests of lossy codecs and presenting statistical analyses of the results. These results show the advantages and disadvantages of different formats and encoders and help identify which are "state of the art."

[[Private Listening Tests|Private listening tests]] also provide useful data, but the public HydrogenAudio tests are a rarity in having enough participants to both average out variations among individual listeners and still have statistically significant results.

Note that a listening test cannot really compare formats or encoder "brands." Instead, it compares particular versions of particular encoders at particular bitrates. Results will differ with different encoders, newer versions of the same encoders, or different bitrates. Use caution when extrapolating, and use the most recent results when extrapolating to the newest encoder versions.

'''Note:''' There would be no point in listening tests of [[lossless]] encoders; the decoded results are bit-identical to the original uncompressed recordings. [[Lossless comparison|Lossless encoder comparisons]] instead consider technical aspects such as compression ratio and encode/decode speed.

All tests are sorted by date, newest first. All dates are in [http://www.cl.cam.ac.uk/~mgk25/iso-time.html ISO8601 format].

==Tests and Results==
{|class="wikitable" align="right"
!colspan=2| Result Symbol Key
|-
| > || Better than
|-
| ~ || About the same as
|-
| ~> || About the same, but slightly better than
|}

===Multiformat Tests===

{| border="1" cellpadding="2" cellspacing="0" style="text-align:center;"
|- style="background:#aaffff"
! Date !! Title Samples !! Performed by !! Codecs !! Result !! Links
|-
| 2014-07
| 96-kbps General
| Kamedo2
| [[Apple AAC]] (iTunes 11.2.2), [[Opus]] (1.1), [[Vorbis]] ([[aoTuV]] Beta6.03), [[MP3]] ([[LAME]] 3.99.5)
| Opus > Apple > MP3(V5) ~ Vorbis
| [http://www.hydrogenaud.io/forums/index.php?showtopic=106354 HA Thread] [http://listening-test.coresv.net/results.htm Complete Result]
|-
| 2011-04-10
| 64-kbps General
| IgorC
| [[Vorbis]] [[aoTuV]], [[QuickTime AAC|Quicktime]] HE-[[AAC]], [[Opus]]
| Opus > Apple > Nero ~ Vorbis
| [http://www.hydrogenaud.io/forums/index.php?showtopic=87785 HA Thread] [http://listening-tests.hydrogenaud.io/igorc/results.html Complete Result]
|-
| 2007-08-16
| 64-kbps General
| Sebastian Mares
| [[Vorbis]] [[aoTuV]], [[Nero AAC]], [[WMA]] Pro
| Nero > WMA Pro ~ Vorbis
| [http://www.hydrogenaud.io/forums/index.php?showtopic=56397 HA Thread] [http://listening-tests.hydrogenaud.io/sebastian/mf-64-1/results.htm Complete Result]
|-
| 2006-11-22
| 48-kbps General
| Sebastian Mares
| [[Vorbis]] [[aoTuV]], [[Nero AAC]], [[WMA]] Pro, [[WMA]] Standard
| Nero > WMA Pro ~ Vorbis > WMA Standard
| [http://www.hydrogenaud.io/forums/index.php?showtopic=50408 HA Thread] [http://listening-tests.hydrogenaud.io/sebastian/mf-48-1/results.htm Complete Result]
|-
| 2006-01-13
| 128-kbps General
| Sebastian Mares
| [[QuickTime AAC]], [[Nero AAC]], [[LAME]] [[MP3]], [[Vorbis]] [[aoTuV]], [[WMA]] Pro
| 5-way tie
| [http://www.hydrogenaud.io/forums/index.php?showtopic=40607&view=findpost&p=357117 HA Thread] [http://listening-tests.hydrogenaud.io/sebastian/mf-128-1/results.htm Complete Result]
|}

===[[AAC]] Tests===

{| border="1" cellpadding="2" cellspacing="0" style="text-align:center;"
|- style="background:#ffaaaa"
! Date !! Title Samples !! Performed by !! Codecs !! Result !! Links
|-
| 2011-08-20
| 96-kbps General
| IgorC
| CT, [[Fraunhofer|FhG AAC]] via Winamp (not [[Fraunhofer FDK AAC|FDK]]), [[Nero AAC|Nero]], [[QuickTime AAC|QuickTime]] TVBR & CVBR
| Quicktime CVBR ~> TVBR ~> Fraunhofer > CT > Nero
| [http://www.hydrogenaud.io/forums/index.php?showtopic=89765 HA Thread] [http://listening-tests.hydrogenaud.io/igorc/aac-96-a/results.html Complete result]
|-
| 2006-02-20
| 48-kbps HE-AAC General
| Gabriel
| 3gpp (v1), CT (v1 & v2), [[Nero AAC|Nero]] (v1 & v2)
| All tie for most sample types; otherwise any v1 > any v2
| [http://www.hydrogenaud.io/forums/index.php?showtopic=42679&hl= HA Thread] [http://www.mp3-tech.org/tests/aac_48/results.html Complete Result]
|-
| 2006-02-05
| 48-kbps HE-AAC Classical
| Ivan Dimkovic
| [[Nero AAC|Nero]] HE-AAC v1 & v2
|
| [http://www.hydrogenaud.io/forums/index.php?showtopic=41191&hl= HA Thread]
|}

===[[MP3]] Tests===

{| border="1" cellpadding="2" cellspacing="0" style="text-align:center;"
|- style="background:#aaffaa"
! Date !! Title Samples !! Performed by !! Codecs !! Result !! Links
|-
| 2008-10-17
| 130-kbps General
| Sebastian Mares
| [[LAME]] 3.97, [[LAME]] 3.98.2, [[iTunes]], [[Fraunhofer|FhG MP3]], [[Xing|Helix]]
|
| {{ha|https://hydrogenaud.io/index.php/topic,66564.0.html|Thread}} [http://listening-tests.hydrogenaud.io/sebastian/mp3-128-1/results.htm Complete Result]
|}

==External Tests==
Other people have held listening tests in venues outside of Hydrogenaudio (although the organizers of the tests tend to be HA members :). The results of these tests are found below:

* [https://web.archive.org/web/20070720024213/http://www.ff123.net/ ff123's site on audio testing and listening tests] (most recent test 2002-07-27)
* [https://web.archive.org/web/20071014001946/http://www.rjamorim.com/test/ Roberto's Public Listening Tests] (most recent test 2004-07-11)
* [http://listening-tests.hydrogenaud.io/sebastian/ Sebastian Mares' Listening Tests] (most recent test updated 2008-11-22)
* [http://www.soundexpert.info/ SoundExpert Listening Tests] (continually updated)

[[Category:Listening Tests]]

Opus

2014-02-27T18:17:42Z

Jensend: /* Web frameworks and browsers */ Correction: Chrome 33 is the first with native Opus playback enabled by default

{{Software Infobox
| name = Opus
| logo = [[Image:opus-logo.png|250px|Official Opus logo]]
| screenshot =
| caption = Opus Interactive Audio Codec
| maintainer = [http://xiph.org/ Xiph.Org Foundation]
| stable_release = 1.0.2
| preview_release = 1.1 beta
| operating_system = Windows, Mac OS/X, Linux/BSD
| use = Encoder/Decoder
| license = 3-clause BSD license
| website = [http://www.opus-codec.org/ opus-codec.org]
}}

'''Opus''' is a [[lossy]] audio compression format developed by the Internet Engineering Task Force (IETF) designed to be suitable for interactive real-time applications over the Internet,{{ref|homepage|a}} including music as well as speech, yet it is also very competitive for use as a storage and playback format, being a [http://people.xiph.org/~greg/opus/ha2011/ class leader at around 64 kbps]. As an open format standardised through [http://tools.ietf.org/html/rfc6716 Request for Comments (RFC) 6716],{{ref|RFC|c}} a high quality reference implementation is provided under the 3-clause BSD license{{ref|homepage|a}} which compiles and runs on the vast majority of general purpose and embedded (fixed point) processors. Many Software patents which cover Opus are licensed under royalty-free terms.{{ref|FAQ|b}} Opus is also a Mandatory To Implement (MTI) codec for the upcoming WebRTC (Web Real Time Communication) specification of the World Wide Web Consortium (W3C).

Opus incorporates technology from two codecs, the speech-oriented SILK codec developed by Skype and the multi-purpose low-latency CELT codec developed by Xiph.org with significant changes to each to ensure they can work together.{{ref|RFC|c}} Opus can seamlessly transition among high and low bitrates, using a linear prediction codec (the SILK layer) at lower bitrates and a lapped transform codec (the CELT layer) at higher bitrates, as well as a hybrid of the two for a short overlap in which SILK encodes the 0-8kHz spectrum and the CELT layer encodes only the frequencies above 8kHz.{{ref|RFC|c}} Opus has very low algorithmic delay (typ 22.5 ms) compared to popular music formats such as [[MP3]], [[Vorbis |Ogg Vorbis]], [[AAC | LC-AAC and HE-AAC]] (all over 100 ms), yet performs very competitively with them in terms of quality per bitrate, making it comparably viable as a storage & playback format. Also unlike Vorbis, Opus does not require the definition of large codebooks for each individual file, making it also preferable for short clips of audio, such as those often used by game developers, a field where patent-free Vorbis is commonly used.{{ref|RFC|c}}

Considerably more details of the history and potential applications for Opus are included in the ''Wikipedia'' page for '''[http://en.wikipedia.org/wiki/Opus_%28audio_format%29 Opus (audio format)]'''

==Characteristics==
Opus supports bitrates from 6kbps to 510kbps for typical stereo audio sources (and a maximum of around 255 kbps per channel for multichannel audio), with the 'sweet spot' for music and general audio around 30kbps (mono) and 40-100 kbps (stereo). It is intrinsically [[VBR | variable bitrate]], though constrained VBR and [[CBR | constant bitrate]] modes are possible where required. In the case of the reference release, libopus, the target bitrate is calibrated against the internal constant quality targets so that over a typical music collection, something very close to the target bitrate will be achieved. This bitrate-calibrated approach differs from most VBR encoders (e.g. LAME, helix mp3, qaac, Nero aacenc, Ogg Vorbis, Musepack) where a setting on some 'constant quality' scale (which differs between encoders) is used and the bitrate will fall where it may. Improved future versions can be expected to offer improved quality at the same setting. Independent implementations may adopt a different approach.

Opus is able to seamlessly adapt its mode of operation without glitches or sound interruption (an illustrative demonstration of [http://opus-codec.org/examples/#gauge bitrate scalability] is on the Opus Examples page), which can be particularly useful for mixed-content audio or varying network conditions, making the unified Opus codec superior to a suite of different codecs that might otherwise cover the same range of bitrate and quality settings and would require out-of-band signalling to instigate codec switching. The switching includes the choice of mono, stereo and other channel mappings, the use of the speech-oriented SILK layer, the general-purpose CELT layer or the hybrid of both, and the use of different audio bandwidths (4kHz, 6kHz, 8kHz, 12kHz, 20kHz) as well as the quality adjustments within the same operating mode that are available in most VBR-capable codecs.

Of importance mainly to interactive uses, but potentially useful in time-delayed audio streaming also, Opus includes packet loss concealment (PLC) in all modes and, in the speech-oriented modes where the SILK layer is active it also supports Forward Error Correction (FEC) where the expected rate of packet loss can be indicated to the encoder by the user or by application software and critical frames (e.g. consonant sounds) can be retransmitted at low bitrate to preserve intelligibility.

For music and general audio, the CELT layer of Opus builds on knowledge gained during xiph.org's Vorbis development and ensures as a primary goal that the total energy in each spectral band is preserved while requiring only a modest bitrate overhead to achieve this, thereby eliminating a lot of bitrate-starvation artifacts such as 'birdies' that are common in low-bitrate MP3, especially during transients, applause and cymbal sounds. This technique likewise increases coding efficiency at bitrates targetting transparent music reproduction. Short blocks (2.5 ms) are also possible for efficient transient handling. Short blocks can also be used exclusively, if very low algorithmic delay (5.0ms) is required to enable very low-latency interative audio (e.g. live networked music performances such as remote jam sessions), though greater bitrate is then required to maintain the same quality (illustrated in [http://people.xiph.org/~xiphmont/demo/celt/demo.html#demo Monty's CELT demo page] under Constant PEAQ value, varying latency). CELT uses a number of additional techniques and provides additional advanced tools to enable encoder tuning.

Opus natively supports [[gapless playback]] (though [[Gapless_playback#Poorly_designed_playback_systems | poor player design]] might itself induce interruptions during playback). Playback gain is also required, making some form of [[ReplayGain]] or [[ReplayGain_2.0_specification | similar]] volume control possible in any compliant player.

==Bitrate performance==
For mono speech, Opus ranges from intelligible narrowband speech reproduction starting at 6 kbps to medium-band, wideband and superwideband speech, reaching full-band speech by around 32 kbps. Above about 32 kbps, the SILK layer is no longer used at all, as CELT alone gives superior quality.

For music, the SILK modes are quite tolerable and better than CELT at very low bitrates. The hybrid mode is adopted as bitrate increases, extending bandwidth first to 12kHz (comparable with compact cassette) then to the full 20kHz and CELT then takes over. Assuming the source is stereo, the transition from mono to stereo typically happens between the transition from 12kHz to 20kHz.

==Indicative bitrate and quality==
The table below gives illustrative, indicative quality guidance based on typical modes used internally by Opus and a range of listening tests.

In the experimental libopus version 1.1-alpha, automatic detection of speech/music and bandwidth detection have been introduced to improve mode decisions, and VBR is less constrained, all with the aim of maximizing the quality/bitrate tradeoff. Thus changes are likely, and this table is likely to require small updates as the encoder is improved.

===Speech encoding quality===
This table assumes a '''monophonic''' source sampled at CD quality or above (typ 48 kHz sampling rate) but mentions stereo compatibility for 40kbps+. The default 20ms frame size (22.5ms latency) is assumed.

{| class="wikitable" style="text-align:center"
|-
!Bitrate target
!Bandwidth
!typ SILK/CELT use
!Speech quality notes
!Use cases/notes/competitive codecs
|-
!1 to 5 kbps
| -
| -
| <6kbps bitrate not supported
| Try [http://codec2.org/ codec2] for 1.2-2.4 kbps speech
|-
!6 kbps
|4 kHz
|SILK
|Fair, intelligible
|AMR-NB may be a little better, but higher latency & proprietary, Speex also competitive
|-
!8 kbps
|4 kHz narrowband
|SILK
|Close to telephone quality
|AMR-NB & AMR-WB similar quality, but higher latency & proprietary. Speex competitive.
|-
!12 kbps
|6 kHz medium-band
|SILK
|Medium bandwidth, better than telephone quality
|Similar quality to AMR-WB
|-
!16 kbps
|8 kHz wideband
|SILK
|Wideband speech quality
|Similar to/better than AMR-WB
|-
!24 kbps
|12 kHz super-wideband
|hybrid
|Near transparent speech
|Better than AMR-WB. Podcasts/audiobooks/talk-radio.
|-
!32 kbps
|20 kHz
|hybrid / possibly CELT
|Essentially transparent speech plus moderately good mono music
|Much better than AMR-WB. Podcasts/audiobooks/talk-radio.
|-
!40 kbps
|20 kHz
|CELT
|Essentially transparent mono or stereo speech, fairly good stereo music
|Stereo podcasts/audiobooks/talk radio with some music
|-
!48 kbps+
|20 kHz
|CELT
|Essentially transparent mono or stereo speech, reasonable music
|Flexible general purpose modes to suit mixed music and speech
|-
|}

===Music encoding quality===
This table assumes a '''stereophonic''' source sampled at CD quality or above (typ 48 kHz sampling rate). Opus will automatically use mono at very low bitrates, though a certain amount of stereo encoding can still be used - content dependent even when mono is specified as the typical stereo mode in the table below.

{| class="wikitable" style="text-align:center"
|-
!Bitrate target
!Stereo mode
!Bandwidth
!typ SILK/CELT use
!Music quality notes
!Use cases/notes/competitive codecs
|-
!6 kbps
|mono
|4 kHz
|SILK
|Poor, muffled sound but intelligible lyrics.
| -
|-
!8 kbps
|mono
|4 kHz
|SILK
|Poor, muffled but OK for bitrate
| -
|-
!14 to 16 kbps
|mono
|6 kHz
|SILK
|Fairly Poor but OK for bitrate
|Perhaps acceptable for incidental music
|-
!22 to 24 kbps
|mono
|8 kHz
|SILK
|Fair but OK for bitrate
|OK for incidental music
|-
!32 kbps
|mono
|12 kHz
|hybrid
|Moderately good mono, reasonably bright treble (c.f. mono cassette)
|Good for podcasts, audiobooks, CELT-only poss for music. Competitor HE-AAC@32kbps is stereo full-band but with annoying artifacts.
|-
!39 to 40 kbps
|stereo
|12 kHz
|hybrid/CELT
|Moderately good stereo, reasonably bright treble (c.f. stereo cassette)
|Stereo podcasts, audiobooks, very low bitrate music
|-
!48 kbps
|stereo
|20 kHz
|CELT
|Full bandwidth stereo music, some artifacts, rarely nasty
|Stereo podcasts, audiobooks, low bitrate music
|-
!64 kbps
|stereo
|20 kHz
|CELT
|Full bandwidth stereo music, nice sound, detectable differences to original (mostly 'not annoying')
|Music storage & streaming. Beat HE-AAC, Vorbis, MP3 in [http://people.xiph.org/~greg/opus/ha2011/ listening test]
|-
!96 kbps
|stereo
|20 kHz
|CELT
|Full bandwidth stereo music, good quality approaching transparency
|Music storage & high quality streaming.
|-
!112 kbps
|stereo
|20 kHz
|CELT
|Fairly close to transparency (needs more testing)
|Music storage & high quality streaming. Very low-latency stereo networked music performance/jam sessions at OK quality (see below table)
|-
!128 kbps
|stereo
|20 kHz
|CELT
|Very close to transparency (needs more testing). Most modern codecs competitive (AAC-LC, Vorbis, MP3)
|Music storage & streaming. Future download music sales.
|-
!256 kbps
|stereo
|20 kHz
|CELT
|Transparent with very low chance of artifacts (a few killer samples still detectable). Most old & new lossy codecs competitive.
|Music storage & streaming, dedicated limited-bandwidth audio links (e.g. wireless, [http://en.wikipedia.org/wiki/Bluetooth_profile#Advanced_Audio_Distribution_Profile_.28A2DP.29 A2DP-bluetooth] type links).
|-
!510 kbps
|stereo
|20 kHz
|CELT
|Maximum possible stereo bitrate target (actual rate often less than 510 for default frame size). Most old and new lossy codecs competitive, plus near-lossless [[lossyWAV]] and [[WavPack | WavPack lossy]]
|Music storage, dedicated limited-bitrate audio links (e.g. wireless, minimum latency high quality audio. LossyWAV and WavPack lossy are very competitive for storage, and WavPack lossy --blocksize=256 may be competitive with minimum latency mode also.
|-
!>510 kbps
| -
| -
| -
|Above Opus bitrate range allowed for stereo sources
|Settle for 510kbps or use [[lossless]], [[lossyWAV]], [[WavPack | WavPack lossy]] or lossy transform/subband codecs like [[Vorbis]], [[Musepack]] at very high settings.
|-
|}

===Lower latency versus quality/bitrate trade-off===
====Packet overhead in interactive applications====
For interactive use on the Internet or other packet-based networks, total bandwidth used will be subject to packet overhead. The more packet headers that are transmitted every second, the greater will be the overhead that is required. For this reason, Opus, while defaulting to 20.0ms frames, supports 60.0ms frames to reduce overhead when transporting low-bitrate SILK frames at the expense of greater latency, which may still be acceptable for speech, and also supports 10.0ms SILK frames to reduce latency somewhat at the expense of packet overhead.

In the CELT layer, which tends to operate at higher bitrates than SILK, 20.0ms frames are the default, but frames of 10.0ms, 5.0ms and 2.5ms are also possible, which directly increases the frame overhead by transmitting more packets per second to achieve lower latency. In addition, as we'll see below it also reduces the quality/bitrate tradeoff of the CELT layer itself.

None of the bitrates mentioned in this article account for the packet overhead.

====CELT layer latency versus quality/bitrate trade-off====
Unlike the SILK layer, which works on fixed 10.0ms blocks, 1, 2 or 6 of which can be combined into an Opus frame, the CELT layer is able to modify the encoding block lengths available to enable its use with shorter frames.

When the CELT layer uses 10.0ms, 5.0ms and 2.5ms frames instead of the default 20.0ms, it must use smaller transform block sizes to achieve this, thereby reducing frequency resolution in the MDCT compared to the default transform window, thus reducing encoding efficiency for tonal signals. To obtain the same frequency precision for a sound divided into shorter transform windows, improved amplitude precision is necessary, resulting in increased bitrate to obtain the same perceptual quality (or conversely lower quality at the same bitrate).

These reduced-latency modes remain efficient for transient signals, which use short blocks anyway.

In all modes, the algorithmic delay consists of the frame size plus an additional 2.5ms delay. The CELT layer requires 2.5ms for MDCT window overlap.

Xiph.org used matched PEAQ scores (approximate perceptual quality assessment made in software) for the CELT0.10 codec that was used as the basis of the CELT layer in the Opus reference release, which indicate the following [http://people.xiph.org/~xiphmont/demo/celt/demo.html#demo approximate equivalent settings] for stereo music.

{| class="wikitable" style="text-align:center"
|-
!Frame size
!Algorithmic delay
!Bitrate to match 64kbps@22.5ms delay
!fractional bitrate increase
|-
!20.0 ms
|22.5 ms
|64.0 kbps
|0.0 %
|-
!10.0 ms
|12.5 ms
|70.4 kbps
|10.0 %
|-
!5.0 ms
|7.5 ms
|84.8 kbps
|32.5 %
|-
!2.5 ms
|5.0 ms
|112.0 kbps
|75.0 %
|-
|}

N.B. This table is useful for interactive streaming only. For music storage & delayed playback or non-interactive streaming, latency reduction is not important and the default 20.0ms frame size is preferable.

== Hardware & Software Support ==

Much of this section is based heavily on the Jan 12th 2013 version of the '''Support''' section of the [http://en.wikipedia.org/wiki/Opus_%28audio_format%29 Wikipedia article], which is more likely to be kept updated and to provide links to further information about the supporting platforms.

The format and algorithms are openly documented and the reference implementation is published as free software. The reference implementation (Opus Audio Tools, opus-tools), consisting of separate encoders and decoders, is published under the terms of a BSD-like license. It is written in C programming language and can be compiled for hardware architectures with or without floating point unit. The accompanying diagnostic tool opusinfo reports detailed technical information about Opus files, including information on the standard compliance of the bitstream format. It is based on ogginfo from the vorbis-tools and therefore, unlike the encoder and decoder, available under the terms of version 2 of the GPL.

=== Commandline binaries & libopus versions ===
The commandline tools of the reference version are available pre-compiled for the most popular operating systems at [http://opus-codec.org/downloads opus-codec.org] and [https://ftp.mozilla.org/pub/mozilla.org/opus/ Mozilla's ftp server]. No other implementations of opus are currently known. The libopus commandline tools include encoder ''opusenc'', decoder ''opusdec'', and with a different license, the ''opusinfo'' opus stream & metadata analyzer.

The '''latest stable release''' is recommended for general use and as of early 2013 is considered competitive with or superior to the best alternative speech or general music encoders at most supported bitrates.

==== libopus v1.0 (recommended latest stable release) ====
Released 11 Sep 2012 when RFC6716 was standardized but mostly fully developed by late 2011.

'''Stable''', '''well-tuned''' ''opusenc'' reference encoder as included in RFC documentation.

CELT layer closely related to CELT 0.10 implements Constrained VBR mode by default (bitrate boost used mainly for transients), plus true CBR.

==== libopus v1.1-alpha ====
Source code released 21 Dec 2012 for testing & user feedback ([https://ftp.mozilla.org/pub/mozilla.org/opus/win32/opus-tools-0.1.6-opus-1.1-alpha-win32.zip win32 binaries]), but not yet considered stable and well tested enough for general release.

CELT layer [http://jmspeex.livejournal.com/11737.html quality improvements] introduced to provide '''unconstrained VBR''' include a rate boost not just for transients but now for highly tonal signals too and rate reduction when stereo image is narrow. There's also a rewrite of its '''transient detection''' code and '''time-frequency analysis''' code, and rewritten '''dynamic allocation''' code (HF/LF tilt and Band Boost) to allow more aggressive changes from the typical static allocation when warranted.

There are many minor improvements to '''speech quality''' in both SILK and CELT layers.

'''DC-rejection''' below 3 Hz also aids quality if inaudible DC offset is present with no effect on deep bass notes.

'''Automatic speech/music detection''' is introduced to optimize encoding mode choices, especially near the bitrate target range (presumably around 24~40kbps) where the encoder may perform best with SILK, hybrid or CELT depending on content type. Below that range SILK performs best for both music & speech, and above it CELT performs best for speech & music. The detection, without look-ahead, takes a second or two typically and will sometimes make incorrect decisions. The developers would be keen to know of examples of its failure.

'''Automatic bandwidth detection''' is also introduced to save wasted bits allocated to absent frequencies, and while easier to implement, developers would also been keen to know of any failure of this feature (potentially caused by aliasing, quantization and dithering/noise-shaping in source material).

=== VoIP software ===
* The voice-chat software Mumble supports Opus as its main codec.
* SIP softphones Phoner and PhonerLite support Opus
* The SIP and IAX2 client SFLphone is being fitted with Opus support.
* Integration of Opus into the Skype client is finished, although no version with Opus support has yet been published.
* TrueConf video conferencing solutions support Opus.
* Opus support is planned for Jitsi 2.0, together with VP8 video
* Empathy may use any format supported in GStreamer, including Opus.
* Line2 has replaced their current codec with Opus. Their iOS app will be the first to be released with the Opus. The Android app will follow later.
* CSipSimple supports Opus, Codec2, G.726 and G.722.1 with an additional plug-in.
* The voice-chat software TeamSpeak 3 supports Opus for voice and music in pre-release server 3.0.7-pre2 and beta client version 3.0.10

=== Web frameworks and browsers ===
* Opus support is mandatory for WebRTC implementations.
* Mozilla supports Opus beginning with version 15 of Firefox and Thunderbird, plus Seamonkey, which is uses shared codebase.
* Depending on the backend in use, Opera supports inline playback of embedded Opus files. Official support for Opus and WebRTC are on the development roadmap.
* Chromium and Google Chrome have audio support as of version 33.
* Maxthon Cloud Browser

=== Streaming audio ===
* Icecast. (examples: [http://dir.xiph.org/by_format/Opus Stream directory by format Opus], [http://smj.delfa.net/opus_64.m3u 64k]/[http://smj.delfa.net/opus_256.m3u 256k] [http://smj.delfa.net/ Smooth Jazz Opus Stream], [http://www.absoluteradio.co.uk/listen/labs.html Absolute Radio Opus Trial] 7 stations at 24,64,96 kbps, [http://icecast.ofdoom.com:8000/burst-opus.ogg Icecast Of Doom 96k]
* Krad Radio
* Liquidsoap

=== Operating systems and desktop multimedia frameworks ===
* In Debian GNU/Linux the Opus development tools and supporting libraries can be installed from the preconfigured repositories in the next stable version ("wheezy") that is expected to be released in early 2013.
* For Microsoft Windows, there are DirectShow filters supporting Opus, including DC-Bass Source Mod and the LAV Filters.
* In GStreamer the integration of Opus support is complete.
* FFmpeg supports decoding and encoding Opus via the external library libopus.

=== Hardware support ===
* Support in [[Rockbox]] is available. This means hardware support for a series of portable media players (including some products from the iPod series by Apple and Sansa, iriver and Archos devices) and with "Rockbox as an Application" (RaaA) also on Android devices.

=== Player software ===
* VLC media player supports Opus since version 2.0.4
* AIMP supports Opus natively as of version 3.20 build 1125 beta 1.
* [[foobar2000]] supports the format natively as of v1.1.14 beta 1.
* Mpxplay supports Opus (using a decoder DLL) as of v1.60 alpha 2
* Android has a number of player apps supporting Opus, including PowerAmp and others.
* [[Winamp]] supports for Opus via [http://forums.winamp.com/showthread.php?p=2925154#post2925154 3rd party plug-in].
* Amarok 2.8 transcoding support for Opus codec if ffmpeg is compiled with support for the libopus library & support for files in Opus codec if Amarok is compiled against recent TagLib.

=== Other software ===
* CDBurnerXP
* MediaCoder
* Report-IT
* [[MP3tag|MP3tag]]

== References & Notes ==

*{{note|homepage|a}}[http://opus-codec.org/ opus-codec.org homepage]
*{{note|FAQ|b}}[http://wiki.xiph.org/OpusFAQ Opus FAQ]
*{{note|RFC|c}}[http://tools.ietf.org/html/rfc6716 IETF RFC 6716]

[[Category:Codecs]]
[[Category:Lossy]]
[[Category:Encoder/Decoder]]

Hydrogenaudio Listening Tests

2012-03-02T01:06:33Z

Jensend: make the changes I described in the Listening Test forum

One of the most visible ways that HydrogenAudio members have shown their enthusiasm for audio quality and their respect for [[TOS 8|scientific principles]] over the years is by organizing and participating in public blind listening tests of lossy codecs and presenting statistical analyses of the results. These results show the advantages and disadvantages of different formats and encoders and help identify which are "state of the art."

[[Private Listening Tests|Private listening tests]] also provide useful data, but the public HydrogenAudio tests are a rarity in having enough participants to both average out variations among individual listeners and still have statistically significant results.

Note that a listening test cannot really compare formats or encoder "brands." Instead, it compares particular versions of particular encoders at particular bitrates. Results will differ with different encoders, newer versions of the same encoders, or different bitrates. Use caution when extrapolating, and use the most recent results when extrapolating to the newest encoder versions.

'''Note:''' There would be no point in listening tests of [[lossless]] encoders; the decoded results are bit-identical to the original uncompressed recordings. [[Lossless comparison|Lossless encoder comparisons]] instead consider technical aspects such as compression ratio and encode/decode speed.

All tests are sorted by date, newest first. All dates are in [http://www.cl.cam.ac.uk/~mgk25/iso-time.html ISO8601 format].

=Multiformat Tests=

{| border="1" cellpadding="2" cellspacing="0" style="text-align:center;"
|- style="background:#aaffff"
! Date !! Title Samples !! Performed by !! Codecs !! Links
|-
| 2011-04-10
| 64-kbps General
| igorc
| [[Vorbis]] [[aoTuV]], Quicktime HE-[[AAC]], [[Opus]]
| [http://www.hydrogenaudio.org/forums/index.php?showtopic=87785 HA Thread] [http://listening-tests.hydrogenaudio.org/igorc/results.html Complete Result]
|-
| 2007-08-16
| 64-kbps General
| Sebastian Mares
| [[Vorbis]] [[aoTuV]], Nero [[AAC]], [[WMA]] Pro
| [http://www.hydrogenaudio.org/forums/index.php?showtopic=56397 HA Thread] [http://listening-tests.hydrogenaudio.org/sebastian/mf-64-1/results.htm Complete Result]
|-
| 2006-11-22
| 48-kbps General
| Sebastian Mares
| [[Vorbis]] [[aoTuV]], Nero [[AAC]], [[WMA]] Pro, [[WMA]] Standard
| [http://www.hydrogenaudio.org/forums/index.php?showtopic=50408 HA Thread] [http://listening-tests.hydrogenaudio.org/sebastian/mf-48-1/results.htm Complete Result]
|-
| 2006-01-13
| 128-kbps General
| Sebastian Mares
| iTunes & Nero [[AAC]], [[LAME]] [[MP3]], [[Vorbis]] [[aoTuV]], [[WMA]] Pro
| [http://www.hydrogenaudio.org/forums/index.php?showtopic=40607&view=findpost&p=357117 HA Thread] [http://listening-tests.hydrogenaudio.org/sebastian/mf-128-1/results.htm Complete Result]
|}

=Single-format Tests=

==[[AAC]]==

{| border="1" cellpadding="2" cellspacing="0" style="text-align:center;"
|- style="background:#ffaaaa"
! Date !! Title Samples !! Performed by !! Codecs !! Links
|-
| 2011-08-20
| 96-kbps General
| igorc
| CT, Fraunhofer IIS, Nero, QuickTime TVBR & CVBR
| [http://www.hydrogenaudio.org/forums/index.php?showtopic=89765 HA Thread] [http://listening-tests.hydrogenaudio.org/igorc/aac-96-a/results.html Complete result]
|-
| 2006-02-20
| 48-kbps HE-AAC General
| Gabriel
| 3gpp (v1), CT (v1 & v2), Nero (v1 & v2)
| [http://www.hydrogenaudio.org/forums/index.php?showtopic=42679&hl= HA Thread] [http://www.mp3-tech.org/tests/aac_48/results.html Complete Result]
|-
| 2006-02-05
| 48-kbps HE-AAC Classical
| Ivan Dimkovic
| Nero HE-AAC v1 & v2
| [http://www.hydrogenaudio.org/forums/index.php?showtopic=41191&hl= HA Thread]
|}

==[[MP3]]==

{| border="1" cellpadding="2" cellspacing="0" style="text-align:center;"
|- style="background:#aaffaa"
! Date !! Title Samples !! Performed by !! Codecs !! Links
|-
| 2008-10-17
| 130-kbps General
| Sebastian Mares
| [[LAME]] 3.97, [[LAME]] 3.98.2, [[iTunes]], [[FhG]], [[Helix]]
| [http://www.hydrogenaudio.org/forums/index.php?showtopic=66564 HA Thread] [http://listening-tests.hydrogenaudio.org/sebastian/mp3-128-1/results.htm Complete Result]
|}

=External Tests=
Other people have held listening tests in venues outside of Hydrogenaudio (although the organizers of the tests tend to be HA members :). The results of these tests are found below:

* [http://ff123.net/ ff123's site on audio testing and listening tests] (most recent test 2002-07-27)
* [http://www.rjamorim.com/test/index.html Roberto's Public Listening Tests] (most recent test 2004-07-11)
* [http://listening-tests.hydrogenaudio.org/sebastian/ Sebastian Mares' Listening Tests] (most recent test updated 2008-11-22)
* [http://www.soundexpert.info/ SoundExpert Listening Tests] (continually updated)

[[Category:Listening Tests]]

Private Listening Tests

2012-03-02T00:54:01Z

Jensend: Move content over from HA listening tests page

Individual hydrogenaudio members have from time to time carried out their own private listening tests. Though individual perception of different kinds of artifacts varies from person to person, these tests provide some additional data points for comparing lossy encoders.

=Single-format Tests=
==[[AAC]]==

{| border="1" cellpadding="2" cellspacing="0" style="text-align:center;"
|- style="background:#ffaaaa"
! Date !! Title Samples !! Performed by !! Codecs !! Links
|-
| style="width:064px" | 2004-12-09
| style="width:174px" | Ahead vs Apple 128-kbps Classical
| style="width:101px" | Guruboolez
| style="width:299px" | iTunes 4.1.052, 4.7.042; Nero 2.5.9.7, 2.9.998 CBR, 2.9.998 VBR
| style="width:110px" | [http://www.hydrogenaudio.org/forums/index.php?showtopic=29924&view=findpost&p=258644 HA Thread]
|-
| 2005-09-05
| 48- & 64-kbps HE-AAC Classical
| Guruboolez
| CT aacPlus v.2 48- & 64-kbps Helix 11.0.0.1897, Nero 3.2.0.20 VBR
| [http://www.hydrogenaudio.org/forums/index.php?showtopic=36868&view=findpost&p=325091 HA Thread]
|}

==[[MP3]]==

{| border="1" cellpadding="2" cellspacing="0" style="text-align:center;"
|- style="background:#aaffaa"
! Date !! Title Samples !! Performed by !! Codecs !! Links
|-
| style="width:064px" | 2004-01-18
| style="width:174px" | Dithering Test (1) Special
| style="width:101px" | Guruboolez
| style="width:299px" | [[MP3]] Decoders: MAD, [[LAME]], Fraunhofer, foobar2000
| style="width:110px" | [http://www.hydrogenaudio.org/forums/index.php?showtopic=17728&view=findpost&p=174740 HA Thread]
|-
| 2004-11-15
| 130-kbps LAME rjamorim
| Guruboolez
| [[LAME]] 3.90.3 ABR, 3.96.1 ABR, 3.96.1 VBR
| [http://www.hydrogenaudio.org/forums/index.php?showtopic=29422&view=findpost&p=253968 HA Thread]
|-
| 2005-01-11
| 128-kbps LAME ff123
| Guruboolez
| [[LAME]] 3.90.3, 3.96.1, 3.97a5
| [http://www.hydrogenaudio.org/forums/index.php?showtopic=30547&view=findpost&p=264411 HA Thread]
|-
| 2005-10-17
| [[LAME]] 3.98 -V5 Classical
| Guruboolez
| [[LAME]] 3.98: -V5, -V5 --vbr-new, -V5 --vbr-new --athaa-sensitivity 1
| [http://www.hydrogenaudio.org/forums/index.php?showtopic=37973&view=findpost&p=335086 HA Thread]
|}

'''''Notes:'''
(1) Performed under extreme listening conditions not reproducible on daily listening.''

==[[MPC]]==

{| border="1" cellpadding="2" cellspacing="0" style="text-align:center;"
|- style="background:#aaaaff"
! Date !! Title Samples !! Performed by !! Codecs !! Links
|-
| style="width:064px" | 2005-06-18
| style="width:174px" | --standard Classical
| style="width:101px" | Guruboolez
| style="width:299px" | 1.01j, 1.15u
| style="width:110px" | [http://www.hydrogenaudio.org/forums/index.php?showtopic=34911&view=findpost&p=306910 HA Thread]
|}

==[[Vorbis]]==

{| border="1" cellpadding="2" cellspacing="0" style="text-align:center;"
|- style="background:#ffffaa"
! Date !! Title Samples !! Performed by !! Codecs !! Links
|-
| style="width:064px" | 2003-06-18
| style="width:174px" | 128-kbps ff123/rjamorim
| style="width:101px" | Guruboolez
| style="width:299px" | GT2 & PCVS
| style="width:110px" | [http://www.hydrogenaudio.org/forums/index.php?showtopic=10555&view=findpost&p=106189 HA Thread]
|-
| 2004-06-17
| 160-kbps Special
| Guruboolez
| CVS, GT3b2, [[aoTuV]]b2, [[aoTuV]]b2+QK
| [http://www.hydrogenaudio.org/forums/index.php?showtopic=22495&view=findpost&p=218681 HA Thread]
|-
| 2004-02-05
| -q4 Transients
| Guruboolez
| RC3 2002-03, RC3 2002-04, 1.01, 1.01 QK2
| [http://www.hydrogenaudio.org/forums/index.php?showtopic=18359&view=findpost&p=180697 HA Thread]
|}

==[[WMA]]==

{| border="1" cellpadding="2" cellspacing="0" style="text-align:center;"
|- style="background:#ffaaff"
! Date !! Title Samples !! Performed by !! Codecs !! Links
|-
| style="width:064px" | 2003-06-18
| style="width:174px" | 128-kbps ff123/rjamorim
| style="width:101px" | Guruboolez
| style="width:299px" | [[WMA]]9 Standard & Pro
| style="width:110px" | [http://www.hydrogenaudio.org/forums/index.php?showtopic=10551&view=findpost&p=106158 HA Thread]
|}

=Multiformat Tests=

{| border="1" cellpadding="2" cellspacing="0" style="text-align:center;"
|- style="background:#aaffff"
! Date !! Title Samples !! Performed by !! Codecs !! Links
|-
| style="width:064px" | 2003-10-11
| style="width:174px" | 130-kbps Classical (Baroque)
| style="width:101px" | Guruboolez
| style="width:299px" | [[AAC]] (FAAC, PsyTel, Nero, QuickTime) [[MP3]] [[LAME]] 3.90.3, [[MPC]] 1.14, [[Vorbis]] GT3b1, [[WMA]]9 Pro
| style="width:110px" | [http://www.hydrogenaudio.org/forums/index.php?showtopic=14091&view=findpost&p=142684 HA Thread]
|-
| 2003-12-13
| 128-kbps Classical
| Guruboolez
| [[AAC]] (iTunes, Nero, FAAC), [[Vorbis]] 1.01, [[WMA]]9, [[MP3]] [[LAME]] 3.93.1
| [http://www.hydrogenaudio.org/forums/index.php?showtopic=16395&view=findpost&p=163116 HA Thread]
|-
| 2004-07-12
| 175-kbps Classical
| Guruboolez
| [[Vorbis]] Megamix -q5,50, -q5,99 -q6,00 [[MP3]] [[LAME]] 3.97a3 -V3, -V2, [[MPC]] -q5
|
[http://www.hydrogenaudio.org/forums/index.php?showtopic=23355&view=findpost&p=225046 HA Thread]
|-
| 2004-12-09
| 130-kbps Classical
| Guruboolez
| [[AAC]] Nero 2.9.9.998 [[Vorbis]] aoTuVb3
|
[http://www.hydrogenaudio.org/forums/index.php?showtopic=29925&view=findpost&p=258645 HA Thread]
|-
| 2005-03-05
| 140-kbps VBR Classical
| Guruboolez
| [[AAC]] Nero 3.0.0.4, [[Vorbis]] 1.1, QK28
|
[http://www.hydrogenaudio.org/forums/index.php?showtopic=32080&view=findpost&p=279240 HA Thread]
|-
| 2005-03-17
| 256-kbps Transcode from MP3 subset of ff123
| Guruboolez
| [[AAC]] iTunes 4.7, [[MP3]] [[LAME]] 3.97a8 [[MPC]] 1.15u, [[Vorbis]] aoTuVb3, [[WavPack]] 4.2b3 Lossy
|
[http://www.hydrogenaudio.org/forums/index.php?showtopic=32440&view=findpost&p=282909 HA Thread]
|-
| 2005-07-11
| 80-kbps Various
| Guruboolez
| [[LAME]] [[MP3]], [[AAC]]-HE and -LC, [[Vorbis]] [[aoTuV]], [[WMA]] Std
| [http://www.hydrogenaudio.org/forums/index.php?showtopic=35438&view=findpost&p=312296 HA Thread]
|-
| 2005-08-09
| 96-kbps Classical & Various
| Guruboolez
| [[LAME]] [[MP3]], [[AAC]],[[Vorbis]] [[aoTuV]] (Lancer), [[MPC]], [[WMA]]
| [http://forum.hardware.fr/hardwarefr/VideoSon/MP3-WMA-AAC-OGG-qualite-kbps-evaluation-sujet-84950-1.htm#t922011 Hardware.fr thread (in French)]
|-
| 2005-08-22
| 180-kbps Classical
| Guruboolez
| [[AAC]], [[MP3]], [[MPC]], [[Vorbis]] [[aoTuV]]b4
| [http://www.hydrogenaudio.org/forums/index.php?showtopic=36465 HA Thread]
|}

Lossless

2012-03-02T00:09:20Z

Jensend: Revamp intro for clarity

Compression is '''lossless''' when decoding the compressed data gives a result which is identical bit-by-bit to the uncompressed original.

Generic file compression formats, like ZIP or RAR, are lossless. However, trying to compress raw audio with those generally results in files which are only slightly- if at all- smaller than the originals. Lossless audio formats take advantage of knowledge about real-world audio data to provide compression ratios averaging around 50% on most music.

[[Lossy]] encoders only attempt to approximate the sound of the original waveform rather than preserving all the information present in it. Losslessly compressed audio will therefore unavoidably be larger than audio compressed with any reasonable [[lossy]] encoder. However, this disadvantage is offset by lossless files' ability to be [[transcoding|transcoded]] to other lossless formats without any quality degradation.

== Popular lossless formats ==
* [[Apple Lossless]] ([[ALAC]])
* [[Free Lossless Audio Codec]] (FLAC)
* [[Lossless Audio]] (LA)
* [[Lossless Predictive Audio Compression]] (LPAC)
* [[Meridian Lossless Packing]] (MLP)
* [[Monkey's Audio]] (APE)
* [[OptimFROG]]
* [[RK Audio]] (RKAU)
* [[Shorten]] (SHN)
* [[TAK]]
* [[TTA]]
* [[WavPack]]
* [[Windows Media Audio|WMA lossless]]

== Oddball Formats ==
There are several old lossless formats that aren't really deserving of having an article all for themselves. Reasons are: lack of widespread support, lack of features, bad efficiency and, most importantly, it seems noone 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

; 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

; RKaudio
* http://www.msoftware.co.nz/downloads_page.php
* http://rksoft.virtualave.net/rkau.html

; Split2000
* 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

Note that currently '''no single format can be considered best for all applications'''. Rather, the best format depends on the ''intended use'', as well as a number of other factors (such as licensing and file structure). For example, Shorten and FLAC are widely used for sharing live music because of their cross-platform support and speed. Monkey's Audio is popular among Windows users for its superior compression ratio.

== Comparisons ==
''Note the specific assumptions and limitations of each comparison; in particular, results are sensitive to the music selected'''

; http://web.inter.nl.net/users/hvdh/lossless/lossless.htm : Includes an interesting graph of encode/decode speeds vs. file size on the All Albums page

; [[Lossless comparison]] : A comparision focusing more on codec features and less on absolute encoding efficiency. Also features a table comparing most popular codecs based on their features.

; http://members.home.nl/w.speek/comparison.htm : Performance Comparison of Lossless Audio Compressors - Compares file size, encode speed, decode speed for [[APE]], [[FLAC]], [[LPAC]], [[WavPack]], Shorten ([[SHN]]), [[RKAU]], [[OptimFROG]], [[LA]], [[WMA | WMA Lossless]]. Updated 5-2003

; http://www.bobulous.org.uk/misc/lossless_audio_2006.html : Lossless audio formats - A comparison of the rip-and-encode speed and album file size of six different lossless formats: [[WAV|uncompressed Wave]], [[FLAC]], [[WavPack]], [[SHN|Shorten]], [[APE|Monkey's Audio]], and [[OptimFROG]]. First published on 22nd May 2006.

== External Links ==
* [http://www.losslessaudioblog.com/ The Lossless Audio Blog] Lossless Audio News & Information Site.

[[Category:Codecs]]

FAQ

2012-03-01T23:04:04Z

Jensend: /* General Audio Compression */ fix spelling error, fudge slightly because of MP3 Surround (which few actually use)

{{stub}}

This is a list of ''Frequently Asked Questions''. The questions are grouped according to their categories, then sorted alphabetically.

Please note that this FAQ provides very short answers; explore the links to get deeper information.

=General Hydrogenaudio Etiquette=

;Why do you stress blind listening / [[ABX]] tests so much?
;Why [http://www.hydrogenaudio.org/forums/index.php?showtopic=3974 TOS #8]?
:'''Short Answer:''' The usual "audiophile" speak of non-audio related terms which are completely subjective and open to redefinition on a whim, are useless for any sort of progression in discussion.
:For more detailed and thoughtful answers, see the description of [[TOS 8]] on this wiki or [http://www.hydrogenaudio.org/forums/index.php?showtopic=11442 this forum discussion.]

=General Audio Compression=

;Can I increase quality by converting a lossy compressed file to a higher-bitrate lossy compressed file?
:'''Short Answer:''' This is called [[Transcoding]], and the answer is '''no'''.

;Does encoding preserve surround info?
:'''Short Answer:''' Depends. Normal MP3 encoding destroys surround sound information. Go see the page on [[lossy]] encoding.
:In addition, check the following links:
:* [http://www.hydrogenaudio.org/forums/index.php?act=ST&f=15&t=4639 Experience of a HA Member with Rear Channel] on the HA Forums

;What is the best audio format?
:'''Short Answer:''' Depends on your needs.
:For a detailed explanation, see [[Audio format guide]].

;Why do encoded files get clipped when the original WAVs are not clipped?
:'''Short answer:'''
:#Quantization errors may cause the signal to clip, and
:#Gibbs phenomenon through the limitation of bandwidth may cause the signal to clip.
:Check the following links for more details:
:* [http://ff123.net/norm.html Explanation on ff123's site]

;What is an ABX blind test?
:Go see [[ABX]]
:In addition, check the following links:
:* [http://www.hydrogenaudio.org/forums/index.php?showtopic=16295& Blind Listening Test Explanation] on the HA Forums

;What is "transparency"?
:Go see [[transparency]]

;Why not use graphs / frequency analysis to compare codecs?
:Nothing can be said about quality or audible difference by looking at pictures, because a [[lossy]] encoder works by removing as much inaudible sounds as possible. A lack of frequencies can well mean that some audible parts are missing (bad work, or too low setting), or that the encoder managed a very good compression, removing a lot of useless things.
:In addition, check the following links:
:* [[lossy|Lossy]] encoding
:* [[lossless|Lossless]] encoding
:* [[frequency analysis]]
:* [http://www.hydrogenaudio.org/forums/index.php?showtopic=7834&st=0&p=77265&#entry77265 Confusion on CBR & VBR thread] on the HA Forums
:* ... and [http://www.hydrogenaudio.org/forums/index.php?showtopic=42646&hl= this thread] for a more sarcastic discussion.

;Is there a way to filter or remove artifacts from poorly-compressed audio?
:Unfortunately, not at this time. While it is true that compressed video can often use filtering or [[post processing]] during playback to improve image quality, the same cannot be said for audio. Video can be smoothed out, but audio cannot. There is also no data that can be recovered from the compressed audio--the artifacts are present because the original data isn't there anymore!
:The following Hydrogenaudio thread has more information: [http://www.hydrogenaudio.org/index.php?showtopic=6729 MP3 Post Processing]

=MP3-related=

;What is MP3Gain? How do I use it? Is it the same as ReplayGain, but for MP3 only?
:Go check [[MP3Gain|this page]].

;Why is joint stereo better than pure stereo ?
:You better [http://www.hydrogenaudio.org/forums/index.php?act=ST&f=15&t=683 start from this HA thread]

=CD-Drives=

;How do I test my drive's C2 accuracy?
:Visit [http://www.exactaudiocopy.de/eac13.html this page].

[[Category:Guides]]

FAQ

2012-03-01T22:58:17Z

Jensend: /* General Hydrogenaudio Etiquette */ mention TOS 8 page

{{stub}}

This is a list of ''Frequently Asked Questions''. The questions are grouped according to their categories, then sorted alphabetically.

Please note that this FAQ provides very short answers; explore the links to get deeper information.

=General Hydrogenaudio Etiquette=

;Why do you stress blind listening / [[ABX]] tests so much?
;Why [http://www.hydrogenaudio.org/forums/index.php?showtopic=3974 TOS #8]?
:'''Short Answer:''' The usual "audiophile" speak of non-audio related terms which are completely subjective and open to redefinition on a whim, are useless for any sort of progression in discussion.
:For more detailed and thoughtful answers, see the description of [[TOS 8]] on this wiki or [http://www.hydrogenaudio.org/forums/index.php?showtopic=11442 this forum discussion.]

=General Audio Compression=

;Can I increase quality by converting a lossy compressed file to a higher-bitrate lossy compressed file?
:'''Short Answer:''' This is called [[Transcoding]], and the answer is '''no'''.

;Does encoding preserves surround info?
:'''Short Answer:''' Depends. MP3 destroys surround sound information. Go see the page on [[lossy]] encoding.
:In addition, check the following links:
:* [http://www.hydrogenaudio.org/forums/index.php?act=ST&f=15&t=4639 Experience of a HA Member with Rear Channel] on the HA Forums

;What is the best audio format?
:'''Short Answer:''' Depends on your needs.
:For a detailed explanation, see [[Audio format guide]].

;Why do encoded files get clipped when the original WAVs are not clipped?
:'''Short answer:'''
:#Quantization errors may cause the signal to clip, and
:#Gibbs phenomenon through the limitation of bandwidth may cause the signal to clip.
:Check the following links for more details:
:* [http://ff123.net/norm.html Explanation on ff123's site]

;What is an ABX blind test?
:Go see [[ABX]]
:In addition, check the following links:
:* [http://www.hydrogenaudio.org/forums/index.php?showtopic=16295& Blind Listening Test Explanation] on the HA Forums

;What is "transparency"?
:Go see [[transparency]]

;Why not use graphs / frequency analysis to compare codecs?
:Nothing can be said about quality or audible difference by looking at pictures, because a [[lossy]] encoder works by removing as much inaudible sounds as possible. A lack of frequencies can well mean that some audible parts are missing (bad work, or too low setting), or that the encoder managed a very good compression, removing a lot of useless things.
:In addition, check the following links:
:* [[lossy|Lossy]] encoding
:* [[lossless|Lossless]] encoding
:* [[frequency analysis]]
:* [http://www.hydrogenaudio.org/forums/index.php?showtopic=7834&st=0&p=77265&#entry77265 Confusion on CBR & VBR thread] on the HA Forums
:* ... and [http://www.hydrogenaudio.org/forums/index.php?showtopic=42646&hl= this thread] for a more sarcastic discussion.

;Is there a way to filter or remove artifacts from poorly-compressed audio?
:Unfortunately, not at this time. While it is true that compressed video can often use filtering or [[post processing]] during playback to improve image quality, the same cannot be said for audio. Video can be smoothed out, but audio cannot. There is also no data that can be recovered from the compressed audio--the artifacts are present because the original data isn't there anymore!
:The following Hydrogenaudio thread has more information: [http://www.hydrogenaudio.org/index.php?showtopic=6729 MP3 Post Processing]

=MP3-related=

;What is MP3Gain? How do I use it? Is it the same as ReplayGain, but for MP3 only?
:Go check [[MP3Gain|this page]].

;Why is joint stereo better than pure stereo ?
:You better [http://www.hydrogenaudio.org/forums/index.php?act=ST&f=15&t=683 start from this HA thread]

=CD-Drives=

;How do I test my drive's C2 accuracy?
:Visit [http://www.exactaudiocopy.de/eac13.html this page].

[[Category:Guides]]

TOS 8

2012-03-01T22:55:00Z

Jensend: add a small dose of derision

Claims about audio quality can ultimately only be justified by scientifically reproducible perceptual tests. Agreement on that fact is what makes hydrogenaudio-- and ''any'' reasoned discussion about audio-- possible. This principle has been enshrined in the eighth article of [http://www.hydrogenaudio.org/forums/index.php?showtopic=3974 hydrogenaudio's Terms of Service]:<blockquote>All members that put forth a statement concerning subjective sound quality, must -- to the best of their ability -- provide objective support for their claims. Acceptable means of support are [[Blind test|double blind listening tests]] ([[ABX]] or [[ABC/HR]]) demonstrating that the member can discern a difference perceptually, together with a test sample to allow others to reproduce their findings. Graphs, non-blind listening tests, waveform difference comparisons, and so on, are not acceptable means of providing support.</blockquote>

A test of audio quality is ''scientific'' only if it is [[Blind test|blind]]. This eliminates the effects of pre-existing opinions, the placebo effect, and other psychological biases so we can consider the audible differences.

Test results are convincing only when they have been shown to be ''reproducible''. A single blind test, while a useful data point, doesn't constitute convincing evidence. Even a single listener's responses to perceptual tests will vary from moment to moment, so a single result could be "due to chance" rather than showing a real quality difference. Statistical methods-- both frequentist and Bayesian-- can help us recognize convincing evidence when we combine the results of multiple observations.

Without agreement to subject all quality claims to scientifically reproducible testing, conversation about audio rapidly devolves into shouting matches about pre-existing opinions and biases, detailed "analyses" of differences in the waveform that are entirely irrelevant to human perception, and attempts to browbeat others into submission by the sheer repetition of impressive-sounding mumbo-jumbo "terms of art" which are completely subjective and therefore communicate nothing.

TOS 8

2012-03-01T22:39:34Z

Jensend: Start the article