Hello,
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:
Reasons:
* 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.
Codecs
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
Anchors:
- LAME MP3 (high) - bit rate yet TBD / High Anchor
- QuickTime/iTunes LC-AAC @48 kbps / Low Anchor
Samples
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
When
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.
Prior to the test, we will conduct public bit rate verification - in order to make sure codecs behave within the bitrate constraints.
So this test will be a mix of CBR (aacPlus) and VBR?
48 kb/s ist very interesting for streaming internet radio. Is VBR generally suitable for this? Otherwise, the result won't be very interesting for streaming.
I have a few samples which you might like, and are fairly easy to make out. Also, I suggest using vorbis as a high anchor (since it will probably win the 128kbps test anyways..)
PM or email me, to get the samples or for further ideas (please do)
About High Anchor:
If MP3, then, a CBR (or ABR) 128kbps will be interesting, as to compare to internet-radio quality, as well as DVD Rips.
Else, i would suggest AAC, with Apple's implementation at 96kbps (CBR? VBR?) (or 128 if 96 is not discernable enough).
And please add avoTuVo Vorbis @ 48kbsp to - just to compare it to AAC+
PS. There are no other pretendents for 48kbps tests - just multiple AAC+(2) and avoTuVo Vorbis - why not to make this test multiformat?
And please add avoTuVo Vorbis @ 48kbsp to - just to compare it to AAC+
[a href="index.php?act=findpost&pid=350142"][{POST_SNAPBACK}][/a]
........
READ!!!
it's an AAC test.
READ!!!
it's an AAC test.
[a href="index.php?act=findpost&pid=350143"][{POST_SNAPBACK}][/a]
Oh sorry, it's my mistake...
But...
There are no other pretendents for 48kbps tests - just multiple AAC+(2) implementations and avoTuVo Vorbis - why not to make this test multiformat?
There are over 4 implementations of AAC-HE, and a 48kbps multiformat test _is_ coming up. It'll just be after we find out which AAC implementation is best at this bitrate.
Oh!
And don't forget - Coding Technologies aacPlus encoder (at least WinAmp variant) have ParametricStereo/Stereo/IndependentStereo modes !
So this test will be a mix of CBR (aacPlus) and VBR?
48 kb/s ist very interesting for streaming internet radio. Is VBR generally suitable for this? Otherwise, the result won't be very interesting for streaming.
Considering the bitrate, it might makes sense to use the contenders in cbr mode.
48 kb/s ist very interesting for streaming internet radio. Is VBR generally suitable for this? Otherwise, the result won't be very interesting for streaming.
I don't think true VBR has too much sense here - we might use manageable bit-rate ABR mode - but this is still not decided.
dimzon
But... There are no other pretendents for 48kbps tests - just multiple AAC+(2) implementations and avoTuVo Vorbis - why not to make this test multiformat?
One of the purposes of this test would be actually to pick up the best HE-AAC/v2 implementations and use them in the upcoming 48 kbps multiformat test.
Multiformat test should include many other formats, like WMA, Real, mp3Pro, etc... - so there definitely won't be space for 5 (five) AAC encoders - that's why we want to make sure the best ones get into the test.
So this test will be a mix of CBR (aacPlus) and VBR?
48 kb/s ist very interesting for streaming internet radio. Is VBR generally suitable for this? Otherwise, the result won't be very interesting for streaming.
[a href="index.php?act=findpost&pid=350125"][{POST_SNAPBACK}][/a]
Are really 48 kbps encoding useful for streaming?
56K can't stream such encodings, CBR or not. Theoretically, it should be possible, but in fact, it doesn't work.
For people having a better download bandwith (the next step is 128 kbps if I'm not wrong), I'm not sure that 48 kbps really makes sense: 64, 80 or even 96 kbps are probably more interesting.
In my opinion, if internet streaming is proposed as practical purpose of the test, then:
- CBR should be used over VBR
- 32 kbps should be prefered to 48 kbps
But if streaming isn't invoked, then:
- 48 kbps is fine
- VBR should be prefered over CBR.
Multiformat test should include many other formats, like WMA, Real, mp3Pro, etc... - so there definitely won't be space for 5 (five) AAC encoders - that's why we want to make sure the best ones get into the test.
[a href="index.php?act=findpost&pid=350150"][{POST_SNAPBACK}][/a]
IMHO nobody can't beat AAC+/Vorbis at such bitrates!
AAC+ and Vorbis are only real concurrents...
there are no any progress in mp3pro, Real, WMA since last lowbitrate test and this encoders defeats to early HE-AAC implementation!
and, in theory, aac+ is better than mp3pro by definition (of couse if AAC+ use good LC encoder and then both use same SBR encoder)
For many people here 48 kbit/s has sence.
It was mentioned it is highest bitrate for PS. Particullart for me 48 kbit/s will be very interesting . I will use for different aplications. Nowdays 56 kbit/s dial-up internet has the same price as cablemodem/dsl 128 kbit/s. there a lot of people who are interesting in 48 kbit/s test.
Hmm - nobody really tested WMA @48 kbps vs. anything else here - and, even if someone did it would be very good to know how codecs compare with each other today, for the further reference.
Otherwise, somebody could always claim that codec X might be better at 48 kbps, as it was not tested, etc...
guruboolez
Are really 48 kbps encoding useful for streaming?
56K can't stream such encodings, CBR or not. Theoretically, it should be possible, but in fact, it doesn't work.
Indeed - maybe good GPRS/EDGE mobile connections could stream that easily.
But there is also another point in 48 (or around) kbps - I believe (yet to be proven) that state-of-the-art could bring significant advantage and lower down the streaming bit rate for DSL connections to 48 kbps for audio - comparable to the MP3 quality of much higher bit rate.
This is important IMHO because of two reasons:
- For the broadcasters, especially online radio stations - it is very important, as they do pay the bandwidth originating from them - and cutting from 100 kbps to 48 kbps means roughly 50% of savings in money spent for bandwidth costs
- Also, for comined audio-video streams, it is very important as more bits will be available for video - if we can prove that 48 kbps state-of-the-art provides comparable quality to higher bit rate solutions, it would be a huge benefit for the video quality, too.
I'm not sure that 48 kbps really makes sense: 64, 80 or even 96 kbps are probably more interesting.
Cell phones or choppy streaming is fine...
And I've seen 56k modems download at 6.7kBps, so streaming 48kbps audio shouldn't be a HUGE problem.. In any case, it's always interesting if you have a DSL line but greatly limited bandwidth, or an ISDN connection (RNIS)
edit : Argh!! Ivan Dimkovic shot the sheriff...
Hmm - nobody really tested WMA @48 kbps vs. anything else here - and, even if someone did it would be very good to know how codecs compare with each other today, for the further reference.
http://www.rjamorim.com/test/64test/results.html (http://www.rjamorim.com/test/64test/results.html)
http://www.rjamorim.com/test/32kbps/results.html (http://www.rjamorim.com/test/32kbps/results.html)
just interpolate results
I wouldn't go interpolating results that easily
By the way, Woodinville also mentioned new WMA coming in January - so it will be perfect timing when the AAC test is done - to put the brand new WMA in the multiformat test
I beleive it wood be much more usable to add old HE-AAC implementation to this test. It will be very intresting to know which progress does Nero do
For many people here 48 kbit/s has sence.
It was mentioned it is highest bitrate for PS. Particullart for me 48 kbit/s will be very interesting . I will use for different aplications. Nowdays 56 kbit/s dial-up internet has the same price as cablemodem/dsl 128 kbit/s. there a lot of people who are interesting in 48 kbit/s test.
[a href="index.php?act=findpost&pid=350158"][{POST_SNAPBACK}][/a]
Right. But if people have a 128 kbps bandwith connection or more, why shouldn't "true VBR [make] much sense here" (Ivan Dimkovic)? Why testing 48 kbps and not 64 or 80 kbps? I'm sorry, but if I had a modern DSL/cable connection, the last thing I'll looking for would be 48 kbps encodings.
At the 32 kbps test WMA and Real were tied with Vorbis.
So this comment:
IMHO nobody can't beat AAC+/Vorbis at such bitrates
just doesn't make sense.
Somebody want test at 32 kbps , another at 64 and higher. Also many people want at 48 kbit/s. It´s difficult to establish an average bitrate to satisfy all users.
48 kbit/s is an average bitrate ... maybe most wanted. I know teh results can be different for 32-48-64-.... bitrates. Or maybe let´s vote (making poll)?
guruboolez
Right. But if people have a 128 kbps bandwith connection or more, why shouldn't "true VBR [make] much sense here" (Ivan Dimkovic)? Why testing 48 kbps and not 64 or 80 kbps? I'm sorry, but if I had a modern DSL/cable connection, the last thing I'll looking for would be 48 kbps encodings.
Well if the VBR is predictable and manageable - and requires no extra long buffering for 48 kbps streaming, I guess it is OK - but have in mind that not all competitors have VBR capabilities.
As for the DSL/Cable connection - I believe that the point of the test is not to show "what is best possible solution for a consumer, concerning audio-only streaming" - as with todays DSL networks, answer is quite simple - modern codec ~128 kbps would do - and we will find out later this year could 96 kbps do, too.
But this is not really about that - I am quite sure that broadcasters and individuals hosting their own radio stations and content libraries would like to know how low they can go without damaging quality too much for ordinary users, and still save some significant bandwidth costs, and also - could they penentrate the upcoming mobile GPRS/EDGE/UMTS market - remember, there it still counts how much you transfer
Also, please have in mind that there are more mobile phones than fixed lines now worldwide.
Also for the user would be interesting if he could get higher quality video - cutting from 128 to 48 kbps is 80 kbps - and that means a lot for streaming video.
Somebody want test at 32 kbps , another at 64 and higher. Also many people want at 48 kbit/s. It´s difficult to establish an average bitrate to satisfy all users.
48 kbit/s is an average bitrate ... maybe most wanted. I know teh results can be different for 32-48-64-.... bitrates. Or maybe let´s vote (making poll)?
[a href="index.php?act=findpost&pid=350168"][{POST_SNAPBACK}][/a]
I have nothing against 48 kbps; I'm not in favor of 32 or 64 kbps instead. But I'm just looking for coherence. Why discarding VBR and using 48 kbps at the same time? If someone can stream 48 kbps (i.e. if he doesn't have a dial-up), then he should be able to handle VBR without problem. No?
[Also for the user would be interesting if he could get higher quality video - cutting from 128 to 48 kbps is 80 kbps - and that means a lot for streaming video.
[a href="index.php?act=findpost&pid=350170"][{POST_SNAPBACK}][/a]
Finally somebody understand me and other people like me, Dimzon froom D9...
AAC+2 epscually good for soundtracks. There is some background music, noises, speech etc. It´s much harder to listen SBR distortion than on music samples.
Why discarding VBR and using 48 kbps at the same time?
Please, use both modes CBR/VBR if possible!
If someone can stream 48 kbps (i.e. if he doesn't have a dial-up), then he should be able to handle VBR without problem. No?
[a href="index.php?act=findpost&pid=350171"][{POST_SNAPBACK}][/a]
Streaming 48kbps on dial-up IS possible.
Somebody want test at 32 kbps , another at 64 and higher. Also many people want at 48 kbit/s. It´s difficult to establish an average bitrate to satisfy all users.
48 kbit/s is an average bitrate ... maybe most wanted. I know teh results can be different for 32-48-64-.... bitrates. Or maybe let´s vote (making poll)?
[a href="index.php?act=findpost&pid=350168"][{POST_SNAPBACK}][/a]
I have nothing against 48 kbps; I'm not in favor of 32 or 64 kbps instead. But I'm just looking for coherence. Why discarding VBR and using 48 kbps at the same time? If someone can stream 48 kbps (i.e. if he doesn't have a dial-up), then he should be able to handle VBR without problem. No?
[a href="index.php?act=findpost&pid=350171"][{POST_SNAPBACK}][/a]
I dont mind about VBR. But it less predictable for final size. In consequence less fair. Maybe ABR will be good.
Finally somebody understand me and other people like me, Dimzon froom D9...
Yeah! AAC+ is perfect choice for soundtrack:
H264 + HE-AAC =MP4 container
Well - theoretically we (Nero) could do CBR, quality (threshold) based VBR, bit rate manageable VBR, ABR with large bit buffer, 2-pass CBR, etc..
I am afraid that we cannot test all that - number of codecs would be too big, I am for using one codec-one mode approach here, otherwise we might be lost in tons of codecs and settings.
2-pass
WOW!!!!!!!!
It means BEST bitrate distribution @ suggested bitrate!
I really like it!
If someone can stream 48 kbps (i.e. if he doesn't have a dial-up), then he should be able to handle VBR without problem. No?
[a href="index.php?act=findpost&pid=350171"][{POST_SNAPBACK}][/a]
Streaming 48kbps on dial-up IS possible.
[a href="index.php?act=findpost&pid=350175"][{POST_SNAPBACK}][/a]
Did you try?
I dont mind about VBR. But it less predictable for final size. In consequence less fair. Maybe ABR will be good.
[a href="index.php?act=findpost&pid=350176"][{POST_SNAPBACK}][/a]
Do you mean that forcing CBR good VBR implementations is really something fair? If VBR perform better than CBR, it should be tested. BTW, VBR should be used in the second test (the multiformat one): Vorbis...
My question is: why discarding VBR (VBR has always be considered as better than CBR/ABR on this board)? Predictible size? Bullshit: VBR has always be priviledged in listening tests. Streaming? Nonsense, because VBR could be stream at ~48 kbps with every kind of internet connection excepted dial-up.
,Dec 14 2005, 05:41 PM]
Streaming 48kbps on dial-up IS possible.
[a href="index.php?act=findpost&pid=350175"][{POST_SNAPBACK}][/a]
Did you try?
[a href="index.php?act=findpost&pid=350181"][{POST_SNAPBACK}][/a]
I did. And it worked. It wasn't HE-AAC, but standard aac. "dans un coin perdu du québec, en plus"
If someone can stream 48 kbps (i.e. if he doesn't have a dial-up), then he should be able to handle VBR without problem. No?
[a href="index.php?act=findpost&pid=350171"][{POST_SNAPBACK}][/a]
Streaming 48kbps on dial-up IS possible.
[a href="index.php?act=findpost&pid=350175"][{POST_SNAPBACK}][/a]
Not here.
WOW!!!!!!!!
It means BEST bitrate distribution @ suggested bitrate!
I really like it!
Problem with 2-pass is that it is not available in the software being shipped, only in the experimental debug encoder - and making it in would take considerable amount of time and modification to make it there, without internal justification and proof that it is actually better (especially compared to ABR which does not require multipass) - so I wouldn't use it for now.
guruboolez
Do you mean that forcing CBR good VBR implementations is really something fair? If VBR perform better than CBR, it should be tested. BTW, VBR should be used in the second test (the multiformat one): Vorbis...
My question is: why discarding VBR (VBR has always be considered as better than CBR/ABR on this board)? Predictible size? Bullshit: VBR has always be priviledged in listening tests. Streaming? Nonsense, because VBR could be stream at ~48 kbps with every kind of internet connection excepted dial-up.
Ok, we will use something that is average 48 kbps and possible to stream without large buffers - as well as highest quality.
I dont mind about VBR. But it less predictable for final size. In consequence less fair. Maybe ABR will be good.
[a href="index.php?act=findpost&pid=350176"][{POST_SNAPBACK}][/a]
Do you mean that forcing CBR good VBR implementations is really something fair? If VBR perform better than CBR, it should be tested. BTW, VBR should be used in the second test (the multiformat one): Vorbis...
My question is: why discarding VBR (VBR has always be considered as better than CBR/ABR on this board)? Predictible size? Bullshit: VBR has always be priviledged in listening tests. Streaming? Nonsense, because VBR could be stream at ~48 kbps with every kind of internet connection excepted dial-up.
[a href="index.php?act=findpost&pid=350185"][{POST_SNAPBACK}][/a]
It´s not b***it. Yes. Predictible size. The idea of HE-AAC2 is save some bits (from 128 kbps to 48 kbps). And If intead of 128 there will be 130-133 kbps then I would say it´s b***it.
It´s not b***it. Yes. Predictible size. The idea of HE-AAC2 is save some bits (from 128 kbps to 48 kbps). And If intead of 128 there will be 130-133 kbps then I would say it´s b***it.
[a href="index.php?act=findpost&pid=350194"][{POST_SNAPBACK}][/a]
Don't make a drama. VBR is enought predictable - You will get approx +/- 8 kbps final bitrate deviation...
It´s not b***it. Yes. Predictible size. The idea of HE-AAC2 is save some bits (from 128 kbps to 48 kbps). And If intead of 128 there will be 130-133 kbps then I would say it´s b***it.
[a href="index.php?act=findpost&pid=350194"][{POST_SNAPBACK}][/a]
Don't make a drama. VBR is enought predictable - You will get approx +/- 8 kbps final bitrate deviation...
[a href="index.php?act=findpost&pid=350195"][{POST_SNAPBACK}][/a]
+/- 8 kbps? Are you serious? No. I want to see 128 kbit/s mp3 and 48 kbps/s HE-aac2. I cant give more bitrate. Not even +/- 2 kbit/s.
VBR is better than ABR. Why is better? VBR has bigger size. Thats all.
ABR two pass should be on par with VBR (or even better). And the size isn´t issue for 135-180kbps. but it´s issue for 48 bkit/s comparing to 128 kbit/s.
But the purpose of this test at low bitrate is to safe some bits.
Guru is pruposing here to use VBR as for 135-180 tests when +/- 100/200 kbyte isn´t issue. But not here.
+/- 8 kbps? Are you serious? No. I want to see 128 kbit/s mp3 and 48 kbps/s HE-aac2. I cant give more bitrate. Not even +/- 2 kbit/s.
[a href="index.php?act=findpost&pid=350196"][{POST_SNAPBACK}][/a]
Not for me - I can sacrify bitrate a little to have const quality... I'm calculating target video bitrate after audio encoding 8kbps is nothing for video!
VBR/CBR issue:
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
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.
[a href="index.php?act=findpost&pid=350200"][{POST_SNAPBACK}][/a]
This is true. The question is: do we need to ensure streaming conditions for 48 kbps encodings? If not, I don't see any reason to
arbitrary discard VBR. Or is there something special with 48 kbps compared to 128 or 32 kbps?
The idea of HE-AAC2 is save some bits (from 128 kbps to 48 kbps).
[a href="index.php?act=findpost&pid=350194"][{POST_SNAPBACK}][/a]
Saving bits is the idea of lossy encoding in general (from PCM to encoded file). And VBR is a tool to gain additional space (by maintaining quality at lower bitrate or increasing quality at the same bitrate than CBR).
Consequently, if you're interesting by efficiency (and you are apparently) you should be interested by VBR.
question: what is the typical aac buffer size for cbr @48kbps?
ISO AAC specifies CBR bit buffer constrains as:
(MAXIMUM_FRAME_SIZE * number_of_channels) - average_frame_length;
Maximum frame size in AAC is 6144 bits
So,
For 48 kHz, Stereo - and 128 kbps AAC bit rate maximum bit reservoir size is
10240 bitsFor 22.05 kHz, Stereo (HE-AAC, AAC operates at fs/2) and 48 kbps it should be
7830 bits.
Note, basically you could speficy much bigger bit reservoirs - but then it would take much longer for the decoders to pre-buffer.
The idea of HE-AAC2 is save some bits (from 128 kbps to 48 kbps).
[a href="index.php?act=findpost&pid=350194"][{POST_SNAPBACK}][/a]
Saving bits is the idea of lossy encoding in general (from PCM to encoded file). And VBR is a tool to gain additional space (by maintaining quality at lower bitrate or increasing quality at the same bitrate than CBR).
Consequently, if you're interesting by efficiency (and you are apparently) you should be interested by VBR.
[a href="index.php?act=findpost&pid=350203"][{POST_SNAPBACK}][/a]
100% agreed
Something is worrying me.
The purpose of this test is to select the best AAC implementation/profile at 48 kbps, in order to get the best contender for the upcoming multiformat listening test at the same bitrate, right?
Shouldn't be fair to do the same for other competitors? I especially have Vorbis in mind. CVS or Aoyumi? resampled -q-1 or orginal one? Several people have reported here than resampling help a lot Vorbis. I didn't really test it myself, but the few encodings I've done confirmed it (resampling -> less distortions).
In other words, there are different settings for Vorbis. Shouldn't we also perform a pre-listening test to get the best vorbis competitor? Could we consider as fair a dedicated pool for AAC but not for others? Personnaly, I wouldn't. As long as different encoders/settings could pretend to be the best, pools (preliminary listening tests) are needed.
Such pool is necessary for AAC, but I'd say that there elements enough to legitimate such pool for Vorbis (CVS-aoTuV / resampling or not / which sampling rate / ?VBR-ABR?).
I don't mind preparing a Vorbis + MP3 test at this same bitrate; Testing FHG, aTouV, LAME and regular vorbis at different settings (default, and resampled, I think, should be enough..)
48kbps Streaming IS reasonable :
http://www.polskastacja.pl/ (http://www.polskastacja.pl/)
Are really 48 kbps encoding useful for streaming?
56K can't stream such encodings, CBR or not. Theoretically, it should be possible, but in fact, it doesn't work.
[a href="index.php?act=findpost&pid=350154"][{POST_SNAPBACK}][/a]
I can confirm that it works (at least here in Germany, but don't ask me what provider since it was on a mate's PC).
For people having a better download bandwith (the next step is 128 kbps if I'm not wrong), I'm not sure that 48 kbps really makes sense: 64, 80 or even 96 kbps are probably more interesting.
[a href="index.php?act=findpost&pid=350154"][{POST_SNAPBACK}][/a]
I think single channel ISDN has 64.
Are really 48 kbps encoding useful for streaming?
56K can't stream such encodings, CBR or not. Theoretically, it should be possible, but in fact, it doesn't work.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=350154")
I can confirm that it works (at least here in Germany, but don't ask me what provider since it was on a mate's PC).
[a href="index.php?act=findpost&pid=350218"][{POST_SNAPBACK}][/a]
[a href="http://www.tuner2.com/]http://www.tuner2.com/[/url] has a lot of 48 kbps streams.
Well, in my opinion, the test should be about how good 48 kbps really can be using recent codecs, and as such VBR should be used, and ABR where VBR isn't appropriate.
Edit: Phrasing
[JAZ] & Serge Smirnoff> I know that 48 kbps stream exists; the problem is that several 56K users can't listen to them. Ask Roberto; he planned to test 48 kbps after his last 128 multiformat test. But several members told him that 48kbps couldn't be properly read with low (56K) connection. Then he switched to 32 kbps as target for his listening test.
So you are pruposing a 32 kbit/s test, right?
So you are pruposing a 32 kbit/s test, right?
[a href="index.php?act=findpost&pid=350362"][{POST_SNAPBACK}][/a]
At all. I just wonder about the choice of testing CBR or ABR -- or any controlled bitrate allocation encoding mode -- over VBR. The arguments I saw don't make sense to my mind.
I could understand why CBR/ABR is privileged over VBR for low bitrate encoding: bitrate must be controlled for streaming. But I don’t know any form of internet connection which could handle CBR 48 kbps but not VBR 48 kbps. Either you have a 56K or less, or you have 128K or more. I don’t know anything between. With 128K, you can safely stream 48K with huge bitrate peak. With 56K, streaming 48 kbps file, even at constant bitrate, is unlikely.
VBR could be discarded for the sake of “predictable size”. It’s indeed interesting for DVD backup (you proposed it, IgorC). But if the purpose of the test is DVD ripping, it wouldn’t make sense to use 44.1@PCM samples when all DVD are using 48KHz sampling rate and are rarely providing LPCM stereo tracks (but rather lossy encoded signal). A “DVD backup listening test at 48 KHz” would interest many people, but then, the chosen samples should obviously be in relation with the object of the test: several speech samples (with and without music), 48 KHz, high dynamic (both loud and very quiet samples) and last but not least AC3 and/or DTS samples as source. We can’t use the worst samples of previous listening tests as Ivan proposed it.
Both arguments (streaming and DVD backup) are going against either the selected bitrate (48 Kbps vs streaming) or the possible application of the test settings (DVD Video ripping vs samples coming from CD Audio). We need some coherence. Are we looking for the best AAC setting in this pre-test? If the answer is positive, then it won’t make sense to discard VBR. Or does someone suddenly dispute the well-known fact that VBR is better than ABR/CBR? If not, if VBR encoders are available and if we’re starting a pre-test for 48 kbps encoders/profile, then we should at least give a try to existing VBR encoders. If we have to discard one encoder/setting (e.g. to limit listening fatigue), it would rather be a CBR one because they’re well-known to provide inferior quality to VBR encoding mode. ABR/CBR are maybe better than VBR at this bitrate, but if someone is tempted to claim this, he should prove it (the burden of the proof lies on people making unusual claims, and VBR<CBR is clearly unusual; so it must be proved – cf. TOS#8).
Therefore, I can't see any valid reason to discard VBR from such test.
It was mentioned 48 kbit/s is very interesting to tests because it´s a highest bitrate for PS. So it test also to evaluate PS.
Guru you already choosed a bitrate that you want 80 - 180 kbps in your previous test. When people asking you to do some test at 48-64 kbit/s you said it´s not interesting for you. So let to us to see some result on 48 kbit/s
You always have choosen a bitrate what you want and now you want that we all hear you always.
So you are pruposing a 32 kbit/s test, right?
[a href="index.php?act=findpost&pid=350362"][{POST_SNAPBACK}][/a]
But I don’t know any form of internet connection which could handle CBR 48 kbps but not VBR 48 kbps. Either you have a 56K or less, or you have 128K or more. I don’t know anything between. With 128K, you can safely stream 48K with huge bitrate peak. With 56K, streaming 48 kbps file, even at constant bitrate, is unlikely.
[a href="index.php?act=findpost&pid=350364"][{POST_SNAPBACK}][/a]
One area for 48kbps would be mobile streaming in GSM EDGE and 3G -networks.
It was mentioned 48 kbit/s is very interesting to tests because it´s a highest bitrate for PS. So it test also to evaluate PS.
Guru you already choosed a bitrate that you want 80 - 180 kbps in your previous test. When people asking you to do some test at 48-64 kbit/s you said it´s not interesting for you. So let to us to see some result on 48 kbit/s
You always have choosen a bitrate what you want and now you want that we all hear you always.
[a href="index.php?act=findpost&pid=350367"][{POST_SNAPBACK}][/a]
It seems that you don't understand. I have nothing against the choice of bitrate. I just
can't see any valid reason TO NOT USE VBR. Is it clearer?
So you are pruposing a 32 kbit/s test, right?
[a href="index.php?act=findpost&pid=350362"][{POST_SNAPBACK}][/a]
But I don’t know any form of internet connection which could handle CBR 48 kbps but not VBR 48 kbps. Either you have a 56K or less, or you have 128K or more. I don’t know anything between. With 128K, you can safely stream 48K with huge bitrate peak. With 56K, streaming 48 kbps file, even at constant bitrate, is unlikely.
[a href="index.php?act=findpost&pid=350364"][{POST_SNAPBACK}][/a]
One area for 48kbps would be mobile streaming in GSM EDGE and 3G -networks.
[a href="index.php?act=findpost&pid=350374"][{POST_SNAPBACK}][/a]
Doesn't it work with VBR? Is streaming already available for mobile?
Doesn't it work with VBR? Is streaming already available for mobile?
[a href="index.php?act=findpost&pid=350376"][{POST_SNAPBACK}][/a]
Should work yeah. I didn't comment against or for VBR, just mentioning one area of use for 48kbps streaming.
It seems that you don't understand. I have nothing against the choice of bitrate. I just can't see any valid reason TO NOT USE VBR. Is it clearer?
[a href="index.php?act=findpost&pid=350375"][{POST_SNAPBACK}][/a]
So why you´re insisting to change bitrate? 32 kbbs ....
I don't agree to use VBR at least for high anchor. For 48 kbps VBR high peak isn't problem but for 128 kbit/s VBR there will be higher peak like 160-180 kbps. It is impossible to stream at 128 kbit/s.
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.
It seems that you don't understand. I have nothing against the choice of bitrate. I just can't see any valid reason TO NOT USE VBR. Is it clearer?
[a href="index.php?act=findpost&pid=350375"][{POST_SNAPBACK}][/a]
So why you´re insisting to change bitrate? 32 kbbs ....
[a href="index.php?act=findpost&pid=350380"][{POST_SNAPBACK}][/a]
His not insisting on changing the bitrate, he's saying that "if we are not to use VBR because we are testing for streaming, why are we testing a bitrate that is not a good choice for streaming (48 kbps)
AtW
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.
I just meant that in CBR for such low bitrates, AAC is not as restricted as MP3 is.
It did not implied that this would be a justification to restrict AAC to cbr.
To me 48kbps is a streaming bitrate, and streaming must be cbr. However, it can feature a big buffer if increased decoding delay is acceptable.
It seems that you don't understand. I have nothing against the choice of bitrate. I just can't see any valid reason TO NOT USE VBR. Is it clearer?
[a href="index.php?act=findpost&pid=350375"][{POST_SNAPBACK}][/a]
So why you´re insisting to change bitrate? 32 kbbs ....
[a href="index.php?act=findpost&pid=350380"][{POST_SNAPBACK}][/a]
Could someone explain him?
EDIT: ATWindsor did
I don't agree to use VBR at least for high anchor. For 48 kbps VBR high peak isn't problem but for 128 kbit/s VBR there will be higher peak like 160-180 kbps. It is impossible to stream at 128 kbit/s.
[a href="index.php?act=findpost&pid=350382"][{POST_SNAPBACK}][/a]
High anchor is here for reference; not to reflect a practical purpose.
High anchor is here for reference; not to reflect a practical purpose.
yes. But later people will say "ah yeah 48 kbit/s PS was clear worth than 128 MP3 " while there won't be ideal 128 but 133-135 kbit/s.
If VBR is better so let's control bitrate ( -V 5 ... -V 7). I.e. size of MP3 128 kbit/s should be 2.67 bigger than 48 kbit/s AAC+2. (128/48)
Gabriel: Is there any reason why streaming must be cbr?
As far as I see, it could be better to use VBR in some cases when streaming: Consider that your stream has an average bitrate of say 96kbps using VBR and you have a reasonably large buffer, would not that sound better than a 96kbps CBR stream? And if the buffer is large enough, it should not be a problem listening to this without chopping using a 128kbps conection.
Gabriel: Is there any reason why streaming must be cbr?
As far as I see, it could be better to use VBR in some cases when streaming: Consider that your stream has an average bitrate of say 96kbps using VBR and you have a reasonably large buffer, would not that sound better than a 96kbps CBR stream? And if the buffer is large enough, it should not be a problem listening to this without chopping using a 128kbps conection.
[a href="index.php?act=findpost&pid=350410"][{POST_SNAPBACK}][/a]
The point of streaming is to listen without a download delay. For such a reason, you have to make sure your stream is constant, or the decoder will have to wait for some parts of it to arrive before being able to decode them. If you're using CBR, it's easy to plan how much of a buffer you'll need to have, to decode the file without skipping.
Well... Lowering the average bitrate of the VBR to 80kbps could still be better than the 96kbps CBR stream while requiring the same buffer. I understand that it is advantageous to have a easily predictable buffer size, though, even though I believe it could be calculated for VBR streams as well.
Well... Lowering the average bitrate of the VBR to 80kbps could still be better than the 96kbps CBR stream while requiring the same buffer. I understand that it is advantageous to have a easily predictable buffer size, though, even though I believe it could be calculated for VBR streams as well.
[a href="index.php?act=findpost&pid=350418"][{POST_SNAPBACK}][/a]
we're talking about 48kps here. 56k modems can't have that sort of overhead.
Anything over 48kps will be skipping. And no, you can't predict the upcoming bitrate (otherwise you wouldn't need 2-pass modes...)
The bitrates were examples, modify them to the 48kbps-range for direct relevance. For instance, it is possible that 40kbps VBR sounds better than 48kbps CBR and at the same time they require the same buffer.
And if everything above 48kbps skips, a buffer isn't used. And as has been said here earlier, it isn't reasonable to expect 56kbps modems to play 48kbps streams reliably. It can be done, but it isn't the scenario one would expect. When I had dial-up, I tried several times and failed 90% of the time.
Lastly, of course you can predict the upcoming bitrate; using some statistics on similar music, artists and masterings should give a reasonable estimate. But that wasn't what was questioned: The question was whether one could easily predict what buffer size would be needed. One way to do this would be to take the song with the highest average bitrate until now and use a buffer size which allows this song to be played smoothly. This isn't a good way to do it, but it is a way to do it, and shows that it is possible.
If a 40kbps VBR never goes above 48 kbps, it will never sound better than 48 kbps cbr..
the same applies to mp3s. preset insane is better than ape or aps because it's the upper limit of the bitrate of any mp3. (also the reason mp3s are the only format to have a cbr value at the top of their quality scale..)
One thing which worries me here - if the part of the this test's purpose would be to decide the best competitor for the 48 kbps multiformat test - then we also have a problem.
Vorbis will be tested in its quality-controlled mode, right?
So, we will compare best CBR encoder from the AAC test with the VBR encoder - which is quite unfair if I may say.
Coding Technologies Enhanced aacPlus (HE-AAC v2) ?
what codec should it be? From winamp, cd-da extractor or it will be provided from codingtechnologies?
To me 48kbps is a streaming bitrate, and streaming must be cbr. However, it can feature a big buffer if increased decoding delay is acceptable.
[a href="index.php?act=findpost&pid=350395"][{POST_SNAPBACK}][/a]
What should be done with Vorbis in the multiformat 48kbps test then? Wonder what kind of screming and complaintments happen if Vorbis will be used in the managed bitrate mode. I think this should be decided before the AAC test.
My opinion is that compare best AAC-HE (PS?) VBR/CBR/ABR 48kbps against Vorbis VBR 48kbps, anyway this would be streamable in high speed mobile networks.
Or then no VBR for anybody, including Vorbis.
I think Winamp was the only software actually being able to use CT's HE-AAC v2 implementation at 48 kbps?
Also, I don't know if using internal encoders from CT is allowed by their demo software agreements, as well as it wouldn't be in accordance to the usual test policies that software should be publically available.
So, I think Winamp would suit the purpose best.
So, I think Winamp would suit the purpose best.
[a href="index.php?act=findpost&pid=350595"][{POST_SNAPBACK}][/a]
It should be checked. CD-DA extractor also has a AAC+2 from CT and it´s very good. I still didnt checked Winamp 5.12 . However imo CD-DA AAC+2 was better than aac+2 from 5.11.
Can more people confirm this? We would use best we can get.
I think Winamp was the only software actually being able to use CT's HE-AAC v2 implementation at 48 kbps?
Helix?
What should be done with Vorbis in the multiformat 48kbps test then? Wonder what kind of screming and complaintments happen if Vorbis will be used in the managed bitrate mode. I think this should be decided before the AAC test.
My opinion is that compare best AAC-HE (PS?) VBR/CBR/ABR 48kbps against Vorbis VBR 48kbps, anyway this would be streamable in high speed mobile networks.
Or then no VBR for anybody, including Vorbis.
I agree that this should be decided before the AAC test.
To me you can only be sure that you can substain the stream in CBR. VBR is only likely to work.
Anyway, if most people here are not interested in the streamability of 48kbps, then use whatever mode is recommended by developpers.
Does helix support HE-AAC2?
More probably it´s the same updated audio encoder in both Winmp 5.12 and CD-DA extractor 9.0.1 from 14 dec. Now both have a same lowpass at 20.5 khz.
Does helix support HE-AAC2?
[a href="index.php?act=findpost&pid=350605"][{POST_SNAPBACK}][/a]
nope only he-aac v1.
I wish very much that someone who can translate Japanese/English will pass along the discussion in this thread to "aoyumi" and the other Japanese Ogg Vorbis developers. They're the carriers of the flame for that format! Double-pass ABR is new to me, but quite possibly they have some experimental builds of that which they could proffer.
Hey, guyz... be calm.
In my opinion "legal" bitrates are a multiplies of standard one: 128 Kbps
So: 8 16 32 64 128 256...
Anyway just my opinion.
That are not multiples of 128, that's just 2^n .
I think the motivation for choice of bit rate and encoding mode is a bit conflicting with some of the aims the test.
The primary choice for the 48 kbps bit rate seems to have been to establish if HE-AACv2 is still beneficial there over HE-AACv1 (apparently consensus is that at 32 kbps v2 is better and at 64 kbps v1?)
But on the same time it must also function as pre-selection for a multiformat test and produce streams that are streamable. Now 48 kbps seems to not be the ideal choice for streaming (too high for dial-up and too low for cable/ADSL), which causes discussion about the encoding mode (if it's not for streaming why use ABR/CBR?) and already looking forward to the multiformat test it causes discussion if Vorbis should restricted to ABR/CBR, while there seems to be (at least according to some people) no real reason for making the stream streamable...
Perhaps this test is trying to do too many things at once?
So, I think Winamp would suit the purpose best.
[a href="index.php?act=findpost&pid=350595"][{POST_SNAPBACK}][/a]
It should be checked. CD-DA extractor also has a AAC+2 from CT and it´s very good. I still didnt checked Winamp 5.12 . However imo CD-DA AAC+2 was better than aac+2 from 5.11.
[a href="index.php?act=findpost&pid=350597"][{POST_SNAPBACK}][/a]
Winamp 5.12 still has the older CT encoder.
Okay, we will use whatever has the latest CT encoder at the time of the test preparation.
Winamp 5.12 has a newer version than previos 5.11 .5.1 ....
Maybe there will be a new 5.13 soon? There were important improvements since then.
Maybe lets wait a little?
Test is anyway scheduled for the late January, so we have one month of time for new releases of the encoders
One area for 48kbps would be mobile streaming in GSM EDGE and 3G -networks.[a href="index.php?act=findpost&pid=350374"][{POST_SNAPBACK}][/a]
Isn't EDGE limited to 384kbps? That should give listeners plenty of room to listen even to 256kbps VBR.
So, we will compare best CBR encoder from the AAC test with the VBR encoder - which is quite unfair if I may say.[a href="index.php?act=findpost&pid=350580"][{POST_SNAPBACK}][/a]
I think you guys should all go with VBR. It'll make everyone happier. Besides, I have my doubts broadcasting stations will actually use test results in their systems. I'm believe noone used mine, at least. All in all, results will only be an interesting curiosity for forum members and other audio geeks.
I think Winamp was the only software actually being able to use CT's HE-AAC v2 implementation at 48 kbps?[a href="index.php?act=findpost&pid=350595"][{POST_SNAPBACK}][/a]
Sorenson Squeeze
About the 48kbps being streamable thing: You guys seem to forget that very few computers are on noiseless enough dial-up lines to get more than 6kBps
constantly. When a streaming station goes about choosing a bitrate to broadcast their content, they must focus on the lowest common denominator and not what some lucky users that live close to the carrier can get.
On bad days here in Brazil, I couldn't even get 24kbps.
Isn't EDGE limited to 384kbps? That should give listeners plenty of room to listen even to 256kbps VBR.
The max supported EDGE speed in the latest phone models seems to be 236.8kbps, 3G UMTS is higher about 384kbps, but there's other things you have to take into account.
1. The real life speed is often much less and varies a lot depending on the current network coverage etc.
2. In many cases you have only limited size of total bandwidth you can use per month, for example 200 or 500MB which is reasonably priced. After this the price per MB will go very high. Of course prices will go down in the future, but this is still an issue in many cases.
3. In other than in the home network roaming prices for data can be incredibly high.
etc.
That's why I think it makes much more sense to stream on average 48kbps (or lower) than a lot higher bitrate music even in high speed mobile networks.
That's why I think it makes much more sense to stream on average 48kbps (or lower) than a lot higher bitrate music even in high speed mobile networks.[a href="index.php?act=findpost&pid=351435"][{POST_SNAPBACK}][/a]
Ah, OK. As I understood it, EDGE would be another reason to use CBR instead of VBR.
But I see it's now obvious that even EDGE would benefit from VBR.
A good reason to use CBR is that the new mobile broadcasting systems like DVB-H, DRM/DRM+, DMB, DAB version 2 etc, will all use CBR HE AAC.
Basically it all goes down to three use models:
1 - Narrowband Streaming over fixed-datarate networks (Digital AM/DRM, DVB-H, ISDN, modem V.90/V.92, etc...)
2 - Narrowband Streaming over variable datarate networks (Internet TCP/IP over higher bitrate DSLs / WLANs, EDGE/3G etc..)
2 - Offline content encoding (e.g. home movie collections, music that will be stored on the mobile playback device, etc...)
For 1, there is no other choice than CBR with strict bit-buffer requirements, otherwise severe bufer overlows/underflows could occur during the playback if the bitrate peak overflows capability of the transmission network. Service quality of these netorks is fixed.
For 2 it is possible to use bit-rate managed VBR, or ABR with bit buffer known a priori - it might require longer pre-buffering (i.e. if we use ABR bit buffer of, say, 64 kilobits - it would require 2-3 seconds of pre-buffer over modem) - but the quality impact might be considerable - note that service quality on such networks might vary so even strict CBR requirements might not be met if the service quality drops considerably.
For 3, it is usually desirable to use VBR, even 2-pass VBR encoding, or ABR with relaxed bit-buffer requirements - as content is usually decoded from the device possesing interface to the medium where compressed audio is stored with datarate capability way above the maximum AAC frame size.
One issue is also that in principle we should test as many samples as possible.
It depends quite a lot on the sample set which AAC-HE mode (V1 or V2 parametric stereo) will win.
Attached couple of samples of CT V1 and V2 where V2-PS is either clearly better or worse than CT V1 in my opinion. (Sorry no new Nero encoder samples yet )
One issue is also that in principle we should test as many samples as possible.
It depends quite a lot on the sample set which AAC-HE mode (V1 or V2 parametric stereo) will win.
Attached couple of samples of CT V1 and V2 where V2-PS is either clearly better or worse than CT V1 in my opinion. (Sorry no new Nero encoder samples yet )
[a href="index.php?act=findpost&pid=351719"][{POST_SNAPBACK}][/a]
For your ears PS was better than simple SBR on 41_30 sample. For me it's killer sample for both. Both have different distortion. I hear on SBR something like hessing and on PS seems like some guitar drive effect.
One thing which worries me here - if the part of the this test's purpose would be to decide the best competitor for the 48 kbps multiformat test - then we also have a problem.
Vorbis will be tested in its quality-controlled mode, right?[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=350580")
At last...
[a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=39731&view=findpost&p=350185]http://www.hydrogenaudio.org/forums/index....ndpost&p=350185[/url]
“BTW, VBR should be used in the second test (the multiformat one): Vorbis...”
Well I know for sure that Nero could supply a variable rate codec - we can do some internal tests to find out what is best.
Actually a smart idea will be to do a small pre-test, where we will determine which Nero coding mode would be the best - I could organize it in the early January.
Actually a smart idea will be to do a small pre-test[a href="index.php?act=findpost&pid=351910"][{POST_SNAPBACK}][/a]
The pre-test of the pre-test? :B
Well yeah - otherwise I have no clue which mode to chose and to be absolutely sure
And it would actually mean a lot to see how VBR is useful at this bitrate.
radio streaming related: just to mention that 'radio out -> encoder' is not perfect path in most cases (for the encoder), some of my tests with real/he-aac confirm that (i could get nice quality with cd sourced samples, but when the actual radio stream was the source all kind of problems were noticable), so in real world this kind of test may be just wishfull theory thats not really usefull.
As the 3gpp reference code only runs on 48kHz samples, we have 2 choices:
*patch it to accept 44.1kHz
*resample input to 48kHz, encode with 3gpp, and resample to 44.1kHz after decoding.
I do not really like the idea of patching it to accept 44kHz, as it could fool its psychoacoustics.
I think that the resampling option is acceptable. The quality decrease because of the 2 resampling steps should be (I think) minor compared to the encoding @ 48kbps.
I think that the resampling option is acceptable. The quality decrease because of the 2 resampling steps should be (I think) minor compared to the encoding @ 48kbps.
[a href="index.php?act=findpost&pid=356797"][{POST_SNAPBACK}][/a]
Agreed
48 kbps Nero AAC mode should be testable next week - I'll organize a small "nero pre-test" which consists of:
HE-AAC:
- 48 kbps CBR
- 48 kbps VBR-1
- 48 kbps VBR-2
- 48 kbps ABR
PS-AAC:
- 48 kbps CBR
- 48 kbps VBR-1
- 48 kbps VBR-2
- 48 kbps ABR
VBR-1 and VBR-2 are both based on quality control, but their scaling is different.
Winners could definitely be used in the upcoming AAC 48 kbps test.
I do not really like the idea of patching it to accept 44kHz, as it could fool its psychoacoustics.
If I remeber correctly the last updated 3gp is already patched to accept as input 44.1 khz. However developer said something about psy problems.
3gp supports PS only up to 36 kbit/s.
I'd like to put an additionnal rule for this test:
Contenders encoders should be publically available at least 15 days before the start of the test.
This would avoid "rushed" encoders with changes made in the last hours before the test.
By "public", you mean "officially" or not?
I would propose the subsequent codec releases on HA, until the entire codec is finalized. We do have a clear and firm release date of the new encoder (fully done and optimized) - but we can finish the coding modes one by one, for the tests - e.g. 5.1 and downsampled SBR are not yet done, SBR is being tuned etc.... and they cannot be done in a week.
I would of course try to respect the 2-week deadline for the modes under test - so proper testing and verification could be done - for example, if we set 48 kbps SBR test to mid-February, I can make sure the finalized 48 kbps coding mode will be ready 2 weeks before, with no changes permitted.
I am sorry that I cannot offer anything better - as the next "official" release of the encoder will be quite a big departure from the earlier strategy and model of usage, and it would take extra time to properly integrate it in other applications.
What I would do - I'd like to do a 1-week or 7 day "nero only" test, maybe at the end of this week, for the best coding mode of Nero Digital AAC - winner would be integrated in the codec that would be ready for testing on February 1st, so the real 48 kbps AAC test could start at February 15th.
I had Garf's recent complaint about WMAPro vs HE-AAC listening test in mind. He considered as unfair to oppose an unavailable encoder (WMAPro 10+) to the lastest public release of the direct contender (Nero).
Wouldn't therefore be also "unfair" to reproduce the same attitude? Shouldn't we use public release for all encoders or ask to all companies if their ready to send us the lastest development version of their product wr're going to test?
Well,
It is up to the organizer of the test to decide - for sure, but here are few points from my side:
- New encoder from Nero is currently being finalized and it is about to be released in a short time - testing something which is older would miss the chance to test the encoder that will completely replace everything older, and also be of higher quality (it is not "mumbo jumbo" these claims can be easily proved by anyone willing to do the test between beta AAC encoder, and the old one).
- It is up to the nature of the test - do the test wants to help development of the codecs, or just reflect the "commercially and officially available state of the art" - I always thought it was the first, and am for testing of anything that can be publically be put online with the commitment that it will be used in the future public release of the software, which you can pretty much get from me (yes, it is official
Also, there are examples of other codecs with similar methodology - for example, Vorbis codecs usually used in the test is not "official vorbis codec" / Xiph Approved but still - development builds - so it could be argued that we should only use "official Xiph Approved SVN build" of Vorbis, which I also find to be absolutely not a good idea - and I am all against that.
For sure, I have no reasons not to include the new AAC encoder in the "official release" of software available at www.nero.com - it is just the change that needs to be done is quite big and it needs to fit in the release schedule of the entire product line (so, not just depending on myself - but IMHO it would be very unfortunate to skip the opportunity to test something quite novel and better and that would be available very soon.
So, my 2 cents - use whatever is:
a) Available publically, or donated to HA for testing purposes without restrictions
and/or
b) Forked/beta projects, regarded by developers or by some other conclusion (DBT test) as the best implementation of the particular codec (e.g. Vorbis independent builds)
As for WMA10+ - I would really like it to be also included in the test, if Microsoft wants to publish it by some acceptable means, and give people right to use it, like we do for the beta Nero AAC builds (basically we give people same rights to use them as for the "official" codecs)... I would be the first to support such test.
But, if MS is unvilling to do so (publish WMA10+) - I don't think we should limit others who are really willing to give out the beta codecs, and cooperate with the HA community in making the software better - IMHO it is the point of HA community, to make the audio coding actually progress over the time. Limiting the test would be a step in the very wrong direction.
Just my 0.02 euros
Here is my proposal:
*You make a pre-test related to your codec, and this test is independant of the "official" 48kbps aac test.
*Contenders of the 48kbps aac test must submit their competitors by the 5th of February, 2006 (23:59 gmt).
*The public 48kbps aac test will start on the 20th of February, 2006. Samples choice will still be discussed between the contenders submission and start of the test. This way we will not have encoders specially tuned for a specific set of samples. (it would be very unlikely to happen, but this way we are sure about it)
To be accepted, a codec contender must either:
a) be publically available inside a full usable product (the product can be the encoder itself if it is a command line version)
b) be publically available as a "48kbps test-specific version" . In this case, developpers have three monthes after the end of this test to package the contender in something that would fit into rule "a)". The final packaged encoder must produce identical results as the version used in the test.
Compliance results for this rule will be clearly mentionned on the test pages.
This is quite restrictive, but prevent "fooling" potential users by presenting test results that would not be representative of the real product.
Practically, it means that Nero would have a 3 monthes delay to incorporate the tested encoder mode into the Burning Rom suite. This have to be into an official release. Of course, there can be other subsequent releases after this one, but this is outside of our current scope.
Gabriel,
I agree with the terms and conditions of the test, the deadline and the requirement to publish the codecs "officially" in the 3 months time frame.
I had Garf's recent complaint about WMAPro vs HE-AAC listening test in mind. He considered as unfair to oppose an unavailable encoder (WMAPro 10+) to the lastest public release of the direct contender (Nero).
Wouldn't therefore be also "unfair" to reproduce the same attitude? Shouldn't we use public release for all encoders or ask to all companies if their ready to send us the lastest development version of their product wr're going to test?
[a href="index.php?act=findpost&pid=357548"][{POST_SNAPBACK}][/a]
Didn't we always publish our encoders?
They're not always in Nero itself yet, but you can still *get* them and test for yourself.
I would like to submit Opticodec-PC FE Enterprise 30-day Evaluation for the default CT entry for the 48kbps test. Posted to streaming-server-users@lists.apple.com by Charles Hintz Orban/CRL Sr. Engineer/Customer Support on 1-17-06. This commercial product is scheduled for release 2-15-06. It has both GUI and CLI for CT aacPlus v2 encoder. It supports MPEG-2 ADTS (.aac), MPEG-4 (.mp4 & .m4a), 3GPP (.3gp) file formats. Available for download here (http://www.hydrogenaudio.org/forums/index.php?act=Attach&type=post&id=2025)
I would like to submit Opticodec-PC FE Enterprise 30-day Evaluation for the default CT entry for the 48kbps test. Posted to streaming-server-users@lists.apple.com by Charles Hintz Orban/CRL Sr. Engineer/Customer Support on 1-17-06. This commercial product is scheduled for release 2-15-06.
Does it mean that Apple will support HE-AAC in QuickTime?
The codec has very similiar characteristics with Winamp 5.12 AAC+2 and CT AAC+2 enabled in CD-DA poikosoft. Lowpass, aac/mp4/m4a containers, 44.1 and 32 khz, CBR ..etc. Maybe it's updated version but still the same encoder.
Nullsoft says there should be a new version soon.
I would like to submit Opticodec-PC FE Enterprise 30-day Evaluation for the default CT entry for the 48kbps test. Posted to streaming-server-users@lists.apple.com by Charles Hintz Orban/CRL Sr. Engineer/Customer Support on 1-17-06. This commercial product is scheduled for release 2-15-06. It has both GUI and CLI for CT aacPlus v2 encoder. It supports MPEG-2 ADTS (.aac), MPEG-4 (.mp4 & .m4a), 3GPP (.3gp) file formats. Available for download here (http://www.hydrogenaudio.org/forums/index.php?act=Attach&type=post&id=2025)
[a href="index.php?act=findpost&pid=358762"][{POST_SNAPBACK}][/a]
Hey,
they don't work in Win 2k SP4..Only for Win XP?
thx and best regards,
iNsuRRecTiON
EDIT: Please see screenshot for the error message:
(http://i1.tinypic.com/mv44zk.jpg)
Reminder:
by the 5th of February, 2006 (23:59 gmt)
As a note - the HE-AAC encoder in Winamp 5.2 Beta is "final". Any changes made to the encoder between now and the final version will all be in the "front end" (config UI, mp4 container handling, etc).
Although I suspect you'll be using one of Coding Technologies' "commercial" encoders instead of the one within Winamp.
I will use the one included into winamp, because of its easy availability to users.
If you suggest 5.2 beta, then I will use this one.
48kbps AAC test (http://www.mp3-tech.org/content/?48kbps%20AAC%20public%20test)
Is it possible to extend the deadline for the codec submissions to 6th, 23:59 GMT - unfortuntely due to some internal delays, and completion of Nero listening test, our new 48 kbps codec won't be ready until 6th (Monday)
Well, yes
Question regarding Winamp: is it possible to encode into HE-AACv2 directly from wav files, or do I have to fool Winamp into thinking that it's ripping from a cd?
Question regarding Winamp: is it possible to encode into HE-AACv2 directly from wav files, or do I have to fool Winamp into thinking that it's ripping from a cd?
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=362180")
[a href="http://www.srcf.ucam.org/~wdhf2/transcoder/]http://www.srcf.ucam.org/~wdhf2/transcoder/[/url]
Question regarding Winamp: is it possible to encode into HE-AACv2 directly from wav files, or do I have to fool Winamp into thinking that it's ripping from a cd?
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=362180")
[a href="http://forum.doom9.org/showthread.php?t=102942]http://forum.doom9.org/showthread.php?t=102942[/url]
Question regarding Winamp: is it possible to encode into HE-AACv2 directly from wav files, or do I have to fool Winamp into thinking that it's ripping from a cd?
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=362180")
And yet still [a href="http://www.rarewares.org/mediacoder]http://www.rarewares.org/mediacoder[/url]
@Gaby,
I'll submit latest encoder in 10-20 mins - running last tests now.
@edit - Encoder submitted, as well as faad.exe modified to print out frame statistics (bits per each frame)
All contenders are now submitted, so let's discuss about samples.
samples discussion (http://www.hydrogenaudio.org/forums/index.php?showtopic=41229)
Just a side and personal note: would the same ITU scale be used in this test? From my experience, I can say that I'm usually bothered by the current one for low bitrate test. To match the ITU scale, I must rank most encodings at 2.0 max (corresponding to the "annoying" state). With an anchor which is doomed to be ranked 1.0, the contenders' evaluation will end with a very small dynamic range(between 1.0 and 2.0). IIRC, it's what happened with last low bitrate test (Roberto's 32 kbps listening test) in which most contender were rated at ~1.5. It was so unconfortable that I finally abort the test and sent to Roberto ~10 samples on 18.
I can't talk for other people, but I'd personaly adapt the scale to the targeted bitrate/quality. I remember that I download once a PDF including a kind of official listening test with HE-AAC; marks were comprise between 0 and 100. It's something I'd like to experiment once: I feel such scale more intuitive than the current four-states (1-2-3-4) one.
That is MUSHRA scale, MUSHRA is standardized in recommendation ITU-R BS.1534, and in general it is much more suitable than well known ITU-R BS.1116, for tests where impairment is very big, like very low bit rate coding. It is usually recommended as the method of choice for such tests.
ABC-HR software would need a modification, though - for the different scale, I dunno how feasible is this in the next two weeks - but if it is doable, I would also agree that this is a very good idea.
More on MUSHRA: http://www.bbc.co.uk/rd/pubs/whp/whp038.shtml (http://www.bbc.co.uk/rd/pubs/whp/whp038.shtml)
when you use abchr-java, the labels at least can be customized, although the 1-5
scale is not.
ff123
Maybe it would be great investigating the efforts to modify the current ABC-HR for Java to allow two test methodologies, as having both BS.1116 and BS.1534 impairment scales would provide a very useful addition to the otherwise great application.
Scale of 0-100 might be much better due to the fact that, I assume, modern HE-AAC codecs at 48 kbps would probably be tied, and larger scale would allow better description of the artifacts by the listeners.
In reality, you do get a scale that has 50 increments (0 to 5 in tenths).
ff123
@ff123 - that is true, you are correct, "dynamic range" of MUSHRA is 2x (not 20x) larger.
Nero test encoder is now available from the test homepage
http://www.mp3-tech.org/content/?48kbps%20...20public%20test (http://www.mp3-tech.org/content/?48kbps%20AAC%20public%20test)
There is also faad modified to print out frame statistics - it could be used to detect frame bit rate distribution among various aac encodes.
It only works with MP4 files. I checked the 48 kbps mode recommended for the test and found no problems/bugs with the bit rate distribution.
Question regarding Winamp: is it possible to encode into HE-AACv2 directly from wav files, or do I have to fool Winamp into thinking that it's ripping from a cd?
[a href="index.php?act=findpost&pid=362180"][{POST_SNAPBACK}][/a]
I'm just curious if it's possible to encode into LC-AAC directly from wav files.
In reality, you do get a scale that has 50 increments (0 to 5 in tenths).
ff123
[a href="index.php?act=findpost&pid=362587"][{POST_SNAPBACK}][/a]
I'd rather say 40 (from 1 to 5). There's no "0" in current ABC/HR software. There's only four big or symbolic steps (if you exclude the full transparency level <=> best mark: 1-2-3-4). With MUSHRA, there are 10 different, big & symbolic steps (0-1-2-3-4-5-6-7-8-9).
I'd rather say 40 (from 1 to 5). There's no "0" in current ABC/HR software. There's only four big or symbolic steps (if you exclude the full transparency level <=> best mark: 1-2-3-4). With MUSHRA, there are 10 different, big & symbolic steps (0-1-2-3-4-5-6-7-8-9).
[a href="index.php?act=findpost&pid=362934"][{POST_SNAPBACK}][/a]
Problem with scales is always the reference. The real problem of the 1...5 scale is that from 3 to 5, you're (supposedly) saying that there is a difference that you notice, but that you could accept as good. ( 3 -> slightly annonying ).
Yet, for some people, a difference is something annyoing ( so, 2 ), and for others, filtered signal, with maybe a bit of stereo collapse and differences in highs could be just slightly annoying, (listenable, but there would be the odd problem, so 3).
When one goes with the first route, there is a scale of 10 points ( 1 to 2) to give a notation. This isn't bad in itself, except when you want to say that the low anchor is noticeably worse, which would be the case, of course.
Having a scale of 100 doesn't help this problem, because one can be pushed to do the same mistakes, although there is more margin.
It would help a bit if the low anchor were not too bad. That would make the scale from 1 to 2 more usable.
IMHO, it was too bad in the Ivan's pre-test. There was no doubt which was the low anchor. It was like comparing a telephone and stereo systems in the same test. For example, I gave the second worst sample 1.4 and the low anchor 1. I would have liked to give the second worst sample something like 1.1 and the low anchor 0. The sample was very annoying, but the low anchor was completely unusable.
In the 128 test the Shine encoder was a better choice. A few times the testers could not distinguish it.
The low anchor should be only a bit worse than the contenders especially when the contenders itself are not anywhere near of transparency.
I think it is fine if the low anchor is occasionally as good or better than the worst contender because the overall quality is low anyway.
[span style='font-size:7pt;line-height:100%']Edit: typo[/span]
I think AAC48 should be a much better low anchor than MP348 used in my test.
As for MUSHRA (BS.1534) vs BS.1116 scales - I'd advise on going with MUSHRA because of the fact it was tested well in the industry (EBU, ITU, etc...) - and it is a standard recommendation, so we don't have to hunt in the dark.
Of course, there is an open issue if it would be possible to change ABC/HR to allow MUSHRA-like test with scaling, too in the next few days.
I'd prefer not to rush to change ABC/HR just before a test. I will set the labels in the same way as in Mushra, but that's all.
However, it might be reasonable to change ABC/HR to allow a real Mushra config before the upcoming multi-format 48kbps test.
Since Gabriel published Nero encoder that will be used in the test, I would kindly ask people to verify the consistency of the coding mode used in the test (VBR - Tape)
Few things need to be correct:
- Average Bit rate, per usually defined rules should be within 10% limits of the target bit rate for the test
- Beta version used in the previous 128 kbps test had a flaw (bug) that triggered unusual bit reservoir behavior (it was drained on the beginning of the file) - this problem has been fixed, and I also provided faad.exe modified to print out frame statistics.
To test it - just pick few long MP4 files (entire tracks) - and decode them with modified faad2:
faad_test myStuff1.mp4>myStuff1.txt
Then, you can open this in Excel and draw a simple graph (distribution over time)
If everything is allright - frame distribution should be uniform or correspond with the perceptual requirements of the track - it should not be enlarged at the beginning like in the buggy version.
I checked the 48 kbps mode recommended for the test and found no problems/bugs with the bit rate distribution.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=362816")
I thought I found a severe bug with the submitted encoders. It seems to happen with both 4.9.9.5 and 4.9.9.6.
description of the bug: resulting MP4-AAC files are either invalid (corrupted) or silent.
I could reproduce the bug on my two computers, but it would be nice if other people could also check this.
Here's [a href="http://gurusamples2.free.fr/nd4995/Liszt.ofr]a sample[/url]. [/b] And here are files I got with the uploaded sample:
- "48 kbps" HE (http://gurusamples2.free.fr/nd4995/Liszt_HE_Q0.mp4)
- "300 kbps" LC (http://gurusamples2.free.fr/nd4995/Liszt_LC_Q10.mp4)
I currently experimented the bug with two files; it seems to occur with both HE and LC profile, at ~48 HE [<-> Q0 with fb2k] and 320 LC [<-> Q10] VBR modes. But it's important to note that this bug is not easy to detect, because it is only revealed while
decoding. There's no visible problem during the encoding stage (which is only faster than usual).
And decoders are not reacting the same on these files:
• faad CLI: decode the file but report the error; decoded file is blank
I already sent this report to Gabriel (test organizer) and to Nero Digital developers. I would only warn people: I advice to
not use this encoder for daily usage (at least if the bug is confirmed).
Second issue (minor this time): gapless feature is broken with this encoder (tested with foobar2000).
bug confirmed with Liszt sample...decoding made also with some dshow players and same result pointed by Guru. (only silence)
Thank you kurtnoise
Logically, one of the testing condition won't be followed (i.e. release of the tested encoder within three months); I doubt that the next Nero will be shiped with a broken encoder just to respect the test condition (http://www.mp3-tech.org/content/?48kbps%20AAC%20public%20test). Will this test be postponed? Or will an exception be made?
I also subbmited another problematic sample http://www.mytempdir.com/456921 (http://www.mytempdir.com/456921) before. I thought bug is produced only here. But I tested on other PC. The same result.
Dear All,
This bug could/will be fixed without altering the performance/quality of the encoded bitstreams.
I will try to make this fixed asap - e.g. before next Monday. I am not sure if this should mean that the test needs to be postponed - I don't believe that fixing of this bug will alter anything else, but if Gabriel and others think it should be postponed I am fine with it.
I also subbmited another problematic sample http://www.mytempdir.com/456921 (http://www.mytempdir.com/456921) before. I thought bug is produced only here. But I tested on other PC. The same result.
[a href="index.php?act=findpost&pid=364830"][{POST_SNAPBACK}][/a]
I could confirm: the bug is the same. It occurs with Q1, Q8, Q9 & Q10. Encodings are corrupted.
Bug is fixed - I will submit the updated version soon (30-40 mins)
Here is a patch that fixes the bitstream issue - It does not change anything else (e.g. bit rate distribution, etc...).
To apply the patch, just replace the ndaudio.dll from the original distribution with the new one, and install the files as specified in the readme.
Hopefully, Gabriel will also replace original ndaudio.dll with the current one (patched)
@Edit - just to make sure that there was no tuning of the encoder for any of the sample: bugfix was merely adding two lines of the code - everyone is free to verify that the encoder behaves the same by doing difference-spectral analysis on any test samples, except of course - the items from Guru and IgorC that shown buggy behavior.
Verified. Sound is slightly warmer with vbrpatch; medium are clearly more defined but bass are less enj...
No, I'm joking Bug is fixed and other files are bit-to-bit identical (tested at least on one complete track).
Service is fast nowadays.
How many time for fixing the gapless issue? My chrono is running!
Thank you Ivan.
Gapless issue won't be fixed before we release the new encoder - because the new release will come with quite a big change in how the encoder is actually being used and deployed.
Currently, it is "patched in" into the old AAC plug-in as a DLL, and that breaks the gapless support. The version which will be released will be quite different
As long as it produces identical results on my tracks, I am fine with this fixed version.
It's good to hear that there will be new Nero AAC encoder however it's not a first time.
Just out of curiosity. Why min. bitrate of Nero AAC is aprox. 3 kbits/s while Itunes 2 kbit/s? Is it specification standard limits (mp4 container, streaming etc.)?
I invistigate OGG bitrate distribution. It's very agressive. On silence min. bitrate is something like 0.6 kbit/s while max. peak bitrate is higher than 200 kbit/ (on hard to encode moments) for VBR q4.25 (approx average 128 kbit). While AAC encoders have more constant distribution.
@IgorC - New encoder is in fact in ndaudio.dll - but we mapped the old plug-in to the new encoder, however we are using ABR modes for all non-CBR profiles ATM, hence the smaller bit rate distribition.
It's good to hear that there will be new Nero AAC encoder however it's not a first time. tongue.gif
Indeed - but this one is a completely rewritten one I would say
Just out of curiosity. Why min. bitrate of Nero AAC is aprox. 3 kbits/s while Itunes 2 kbit/s?
I have no info about it - will investigate.
Indeed - but this one is a completely rewritten one I would say
Yes. It's simple to see. Now lowpass is more "adaptive". Something like adaptive quantization. New psycoacustic system?
New encoder is in fact in ndaudio.dll - but we mapped the old plug-in to the new encoder, however we are using ABR modes for all non-CBR profiles ATM, hence the smaller bit rate distribition.
Is it possible to public ndaudio.dll API? Maybe I can write command-line frontend for it to provide all features for testing?
Seems like there are at least 2-pass encoding - related API (aacenc_firstpass_open, aacenc_secondpass_open)
new patched dll is already here. Look in this topic
new patched dll is already here. Look in this topic
[a href="index.php?act=findpost&pid=365043"][{POST_SNAPBACK}][/a]
I'm asking not dll itself but it's API (ie - function prototypes) to be able call them from command-line frontend
new patched dll is already here. Look in this topic
[a href="index.php?act=findpost&pid=365043"][{POST_SNAPBACK}][/a]
I'm asking not dll itself but it's API (ie - function prototypes) to be able call them from command-line frontend
[a href="index.php?act=findpost&pid=365044"][{POST_SNAPBACK}][/a]
My mistake. It would be interesting to see 2 pass.
My mistake. It would be interesting to see 2 pass.
[a href="index.php?act=findpost&pid=365045"][{POST_SNAPBACK}][/a]
I believe every AAC fanatic (like I am) will be happy to play with new (even alpha) Nero AAC encoder and check every it's feature ASAP
@Ivan Dimkovic
Dear Ivan
IgorC told me via ICQ that Nero approved it's beta AAC encoder dll redistribution for 3 month (for testing puposes). Unfortunally IgorC can't find this post. Is it true? Can You point me this post?
Thanx!
I can´t remeber and maybe I interpretated badly the info from here http://www.mp3-tech.org/content/?48kbps%20...20public%20test (http://www.mp3-tech.org/content/?48kbps%20AAC%20public%20test).
But certainly without ilegal tents .
I'm asking not dll itself but it's API (ie - function prototypes) to be able call them from command-line frontend
Well... let me put it in this way, I sincerely hope there won't be a need for the API's in order to use the new encoder in the most configurable way. For the rest, I am afraid you will have to wait for the release to figure out
IgorC told me via ICQ that Nero approved it's beta AAC encoder dll redistribution for 3 month (for testing puposes). Unfortunally IgorC can't find this post. Is it true? Can You point me this post?
Actually, not really - We gave right to Gabriel to put the encoder online, and to allow users to download it (intended for the test evaluation purposes actually) - there is a disclaimer that it is a beta product and no warranty of any kind is given for it.
People should not "redistribute" these binaries - because they are beta and considered as very unstable and also they are part of unfinished product - so using is solely at user's own risk.
I sincerely hope there won't be a need for the API's in order to use the new encoder in the most configurable way. For the rest, I am afraid you will have to wait for the release to figure out
thanx anyway
Seems like We take some extra acitivity
Try "Just the two of us" by Bill Withers, the first 40 seconds or so. Enjoy the organ.