48 kbps AAC Encoders Test - Q1 2006 Edition
48 kbps AAC Encoders Test - Q1 2006 Edition
Dec 14 2005, 14:45
Nero MPEG4 developer
Joined: 22-September 01
Member No.: 8
This is the invitation for a discussion about 48 Kbps AAC test, that should be done before the next 48 kbps multiformat listening test.
Gabriel from LAME development team and myself decided to organize this test - there are few reasons why this test should be organized, and why it should be organized before the next 48 kbps multiformat test:
* Test the state-of-the-art HE-AAC v1 and HE-AAC v2 (Parametric Stereo) commercial encoders, as well as non-commercial 3GPP reference encoder
* Evaluate the usefullnes of Parametric Stereo tool at bit rate of 48 Kb/s
* Make the pre-selection of the best HE-AAC/HE-AAC v2 solutions for the multiformat listening test
* Compare all these solutions with the low-anchored Low Complexity (LC) AAC, in order to verify how the technology has improved over past few years
* Compare against higher bit rate MP3 to verify how much could state-of-the-art 48 kbps codec approach the good old MP3 technology at significantly higher bit rate.
Which high bit rate of MP3 should be used is debatable - should it be 80, 96 or 128 kbps - as stated above, this is open for debate.
At this point (alphabetically):
- 3GPP Reference Encoder
- Coding Technologies aacPlus (HE-AAC)
- Coding Technologies Enhanced aacPlus (HE-AAC v2)
- Nero Digital HE-AAC v1
- Nero Digital HE-AAC v2
- LAME MP3 (high) - bit rate yet TBD / High Anchor
- QuickTime/iTunes LC-AAC @48 kbps / Low Anchor
My idea was to use combined sample set from multiformat 128 kbps listening test and previous Roberto's 64 kbps multiformat test - I thought of chosing several (5-6) samples from both of these two sets by using the worst scored samples.
Worst scored = Lowest average subjective difference grade (SDG) for all codecs in the particular set, except the low and (where applicable) high anchors.
Gabriel's addition was:
* 1 spoken (german male speech?)
* 1 with strong L/R differences, in order to know how PS fares in bad conditions. Something like some old Beatles songs, with singer on 1 channel and instruments on the other one.
Sample selection is definitely open for further discussion here
Test should happen at the end of January - to make enough break after the current 128 kbps multiformat test.
Encoding Settings, Encoders, Bit Rates
Like with all other tests, we won't be testing closed or produced solutions - encoders used in the test will be widely available - as well as encoding settings and encoding material. Regarding the Coding Technologies' aacPlus encoder, my proposal is to use their imlpementation in the Winamp, which is widely available product.
Prior to the test, we will conduct public bit rate verification - in order to make sure codecs behave within the bitrate constraints.
Dec 14 2005, 18:43
Joined: 1-October 01
From: Nanterre, France
Member No.: 138
As you know, modern codecs are using a bit reservoir. It can be directly handled in frames (like mp3), or handled by a regulation part (like some mpeg4 modes).
If your encoder respects the normative constraints regarding CBR, then it is cbr, altough its instantaneous bitrate can vary.
CBR is a way to be sure that you can transmit the stream using a given bandwidth, provided that the decoder has a specific buffer size.
The mp3 cbr is very restricted, as the bit reservoir is only 4088 bits. The AAC reservoir is way higher than that, allowing more large instantaneous fluctuations while still beeing cbr.
If you are using VBR but are enforcing a given average bitrate over a given sliding time slice, then the same bit allocation could be achieved in cbr with a bit reservoir (or whatever its name) that would be the size of your given time slice.
IE: if allowed instantaneous variation is big enough, VBR does not provide any advantage while trying to keep a resonable decoding buffer and a given average bitrate.
question: what is the typical aac buffer size for cbr @48kbps?
edit: bytes -> bits
This post has been edited by Gabriel: Dec 14 2005, 23:43
Dec 15 2005, 15:39
Joined: 3-January 05
Member No.: 18803
QUOTE (Gabriel @ Dec 14 2005, 09:43 AM)
The mp3 cbr is very restricted, as the bit reservoir is only 4088 bits. The AAC reservoir is way higher
So why we should give a prior for mp3? If mp3 is based on old tech and AAC is more flexible. It's only problem for mp3 and not for AAC.
I.e if codec support more advanced features and other no, itīs not reason to disable them.
The same thing happening with video. Some h.264 codecs still doesnt support High Profile but only main profile. So itīs not reason to test all h.264 codecs as they were main profile.
This post has been edited by IgorC: Dec 15 2005, 15:43
|Lo-Fi Version||Time is now: 4th September 2015 - 06:54|