HydrogenAudio

Hydrogenaudio Forum => Listening Tests => Topic started by: Ivan Dimkovic on 2005-12-14 13:45:56

Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2005-12-14 13:45:56
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: elmar3rd on 2005-12-14 14:15:03
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Shade[ST] on 2005-12-14 14:21:45
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)
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: [JAZ] on 2005-12-14 15:22:32
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).
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: dimzon on 2005-12-14 15:26:15
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?
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Shade[ST] on 2005-12-14 15:28:17
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: dimzon on 2005-12-14 15:30:53
Quote
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?
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Shade[ST] on 2005-12-14 15:32:05
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: dimzon on 2005-12-14 15:37:33
Oh!
And don't forget -  Coding Technologies aacPlus encoder (at least WinAmp variant) have ParametricStereo/Stereo/IndependentStereo modes !
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Gabriel on 2005-12-14 15:38:37
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2005-12-14 15:40:14
Quote
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.

Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: guruboolez on 2005-12-14 15:52:40
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: dimzon on 2005-12-14 16:02:42
Quote
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)
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: IgorC on 2005-12-14 16:07:12
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2005-12-14 16:09:37
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...

Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Shade[ST] on 2005-12-14 16:12:08
Quote
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...
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: dimzon on 2005-12-14 16:15:41
Quote
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 
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2005-12-14 16:18:17
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
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: dimzon on 2005-12-14 16:18:44
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
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: guruboolez on 2005-12-14 16:19:52
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: stephanV on 2005-12-14 16:23:51
At the 32 kbps test WMA and Real were tied with Vorbis.

So this comment:
Quote
IMHO nobody can't beat AAC+/Vorbis at such bitrates

just doesn't make sense.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: IgorC on 2005-12-14 16:27:10
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)?
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2005-12-14 16:33:25
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: guruboolez on 2005-12-14 16:33:54
Quote
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?
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: IgorC on 2005-12-14 16:36:55
Quote
[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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: dimzon on 2005-12-14 16:40:05
Quote
Why discarding VBR and using 48 kbps at the same time?

Please, use both modes CBR/VBR if possible!
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Shade[ST] on 2005-12-14 16:41:39
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: IgorC on 2005-12-14 16:42:06
Quote
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: dimzon on 2005-12-14 16:43:00
Quote
Finally somebody understand me and other people like me, Dimzon  froom D9...

Yeah! AAC+ is perfect choice for soundtrack:
H264 + HE-AAC =MP4 container
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2005-12-14 16:43:20
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: dimzon on 2005-12-14 16:48:20
Quote
2-pass

WOW!!!!!!!!
It means BEST bitrate distribution @ suggested bitrate!
I really like it!
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: guruboolez on 2005-12-14 16:53:05
Quote
Quote
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?
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: guruboolez on 2005-12-14 17:00:09
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Shade[ST] on 2005-12-14 17:02:58
Quote
Quote
,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"
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Atlantis on 2005-12-14 17:03:36
Quote
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2005-12-14 17:07:09
Quote
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.

Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: IgorC on 2005-12-14 17:10:50
Quote
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: dimzon on 2005-12-14 17:13:56
Quote
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...
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: IgorC on 2005-12-14 17:16:18
Quote
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: dimzon on 2005-12-14 17:21:49
Quote
+/- 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!
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Gabriel on 2005-12-14 17:43:31
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
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: guruboolez on 2005-12-14 17:51:08
Quote
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?
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: guruboolez on 2005-12-14 17:56:11
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2005-12-14 18:04:13
Quote
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 bits

For 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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: dimzon on 2005-12-14 18:04:23
Quote
Quote
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
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: guruboolez on 2005-12-14 18:14:28
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?).
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Shade[ST] on 2005-12-14 18:37:29
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..)
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: [JAZ] on 2005-12-14 19:34:01
48kbps Streaming IS reasonable :

http://www.polskastacja.pl/ (http://www.polskastacja.pl/)
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Sebastian Mares on 2005-12-14 19:44:41
Quote
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).

Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Serge Smirnoff on 2005-12-14 23:21:39
Quote
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: NoXFeR on 2005-12-15 01:00:51
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
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: guruboolez on 2005-12-15 09:35:01
[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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: IgorC on 2005-12-15 13:54:55
So you are pruposing a 32 kbit/s  test, right?
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: guruboolez on 2005-12-15 14:01:20
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: IgorC on 2005-12-15 14:09:43
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: JohnV on 2005-12-15 14:21:02
Quote
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: guruboolez on 2005-12-15 14:21:37
Quote
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?
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: guruboolez on 2005-12-15 14:22:18
Quote
Quote
Quote
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?
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: JohnV on 2005-12-15 14:24:31
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: IgorC on 2005-12-15 14:26:12
Quote
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 ....
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: IgorC on 2005-12-15 14:33:35
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: IgorC on 2005-12-15 14:39:21
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: ATWindsor on 2005-12-15 15:15:53
Quote
Quote
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
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Gabriel on 2005-12-15 15:20:35
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: guruboolez on 2005-12-15 15:24:23
Quote
Quote
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
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: guruboolez on 2005-12-15 15:27:36
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: IgorC on 2005-12-15 16:36:45
Quote
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)
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: NoXFeR on 2005-12-15 16:40:50
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Shade[ST] on 2005-12-15 16:45:51
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: NoXFeR on 2005-12-15 16:57:11
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Shade[ST] on 2005-12-15 17:36:54
Quote
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...)
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: NoXFeR on 2005-12-15 17:51:27
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Shade[ST] on 2005-12-15 19:06:21
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..)
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2005-12-16 11:28:37
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: IgorC on 2005-12-16 13:01:26
Coding Technologies Enhanced aacPlus (HE-AAC v2) ?

what codec should it be? From winamp, cd-da extractor or it will be provided from codingtechnologies?
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: JohnV on 2005-12-16 13:41:06
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2005-12-16 13:41:25
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: IgorC on 2005-12-16 13:45:37
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2005-12-16 14:07:38
Can more people confirm this?  We would use best we can get.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Gabriel on 2005-12-16 14:18:09
Quote
I think Winamp was the only software actually being able to use CT's HE-AAC v2 implementation at 48 kbps?

Helix?

Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: IgorC on 2005-12-16 14:19:47
Does helix support HE-AAC2?
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: IgorC on 2005-12-16 14:29:04
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: kurtnoise on 2005-12-16 17:33:21
Quote
Does helix support HE-AAC2?
[a href="index.php?act=findpost&pid=350605"][{POST_SNAPBACK}][/a]

nope only he-aac v1.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: ckjnigel on 2005-12-16 18:43:34
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: PatchWorKs on 2005-12-19 11:20:23
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: stephanV on 2005-12-19 11:59:34
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?
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: benski on 2005-12-19 16:11:04
Quote
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2005-12-19 17:14:17
Okay, we will use whatever has the latest CT encoder at the time of the test preparation.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: IgorC on 2005-12-19 21:54:10
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?
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2005-12-20 00:16:09
Test is anyway scheduled for the late January, so we have one month of time for new releases of the encoders
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: rjamorim on 2005-12-20 00:34:03
Quote
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.

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

Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: JohnV on 2005-12-20 13:16:23
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: rjamorim on 2005-12-20 23:32:56
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: digitalradiotech on 2005-12-21 11:48:10
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2005-12-21 11:55:38
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: JohnV on 2005-12-21 19:32:21
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  )
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: IgorC on 2005-12-22 13:51:06
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: guruboolez on 2005-12-22 13:59:42
Quote
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...”

Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2005-12-22 14:01:39
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2005-12-22 15:59:46
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: rjamorim on 2005-12-22 23:07:17
Quote
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
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2005-12-22 23:19:22
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: smok3 on 2005-12-23 02:18:10
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Gabriel on 2006-01-13 16:48:34
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: dimzon on 2006-01-13 16:55:35
Quote
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
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2006-01-13 19:25:11
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: IgorC on 2006-01-13 21:19:28
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Gabriel on 2006-01-16 11:52:02
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: guruboolez on 2006-01-16 11:57:49
By "public", you mean "officially" or not?
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2006-01-16 12:09:47
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: guruboolez on 2006-01-16 12:14:39
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?
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2006-01-16 12:30:24
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
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Gabriel on 2006-01-16 13:13:47
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2006-01-16 13:16:52
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Garf on 2006-01-16 18:30:28
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: paradynamic on 2006-01-21 13:38:23
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)
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: IgorC on 2006-01-21 13:58:36
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: iNsuRRecTiON on 2006-01-30 19:46:25
Quote
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)
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Gabriel on 2006-02-03 16:38:36
Reminder:
by the 5th of February, 2006 (23:59 gmt)
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: benski on 2006-02-03 17:21:48
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Gabriel on 2006-02-04 12:30:06
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Gabriel on 2006-02-05 14:26:40
48kbps AAC test (http://www.mp3-tech.org/content/?48kbps%20AAC%20public%20test)
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2006-02-05 18:15:38
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)
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Gabriel on 2006-02-05 22:22:05
Well, yes 
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Gabriel on 2006-02-05 22:23:52
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?
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: IgorC on 2006-02-05 22:43:39
Quote
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]
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: dimzon on 2006-02-06 12:08:15
Quote
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]
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: [JAZ] on 2006-02-06 19:11:46
Quote
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]
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2006-02-06 21:56:33
@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)
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Gabriel on 2006-02-07 08:39:25
All contenders are now submitted, so let's discuss about samples.
samples discussion (http://www.hydrogenaudio.org/forums/index.php?showtopic=41229)
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: guruboolez on 2006-02-07 14:51:17
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. 
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2006-02-07 15:15:56
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)
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: ff123 on 2006-02-07 15:47:00
when you use abchr-java, the labels at least can be customized, although the 1-5
scale is not.

ff123
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2006-02-07 20:21:19
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: ff123 on 2006-02-07 20:25:14
In reality, you do get a scale that has 50 increments (0 to 5 in tenths).

ff123
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2006-02-07 20:39:31
@ff123 - that is true, you are correct, "dynamic range" of MUSHRA is 2x (not 20x) larger.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Gabriel on 2006-02-08 18:47:39
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)
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2006-02-08 18:52:36
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Enig123 on 2006-02-09 07:34:05
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: guruboolez on 2006-02-09 09:29:54
Quote
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).
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: [JAZ] on 2006-02-09 11:59:33
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Alex B on 2006-02-09 12:33:47
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]
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2006-02-09 14:55:15
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Gabriel on 2006-02-09 15:31:47
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2006-02-11 12:49:38
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: guruboolez on 2006-02-16 20:47:06
Quote
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).
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: kurtnoise on 2006-02-16 21:15:12
bug confirmed with Liszt sample...decoding made also with some dshow players and same result pointed by Guru. (only silence)
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: guruboolez on 2006-02-16 21:24:17
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?
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: IgorC on 2006-02-16 21:51:08
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2006-02-16 22:26:29
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: guruboolez on 2006-02-16 22:28:21
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2006-02-16 22:44:10
Bug is fixed - I will submit the updated version soon (30-40 mins)
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2006-02-16 23:04:38
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: guruboolez on 2006-02-16 23:23:40
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2006-02-16 23:33:23
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
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Gabriel on 2006-02-17 08:47:00
As long as it produces identical results on my tracks, I am fine with this fixed version.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: IgorC on 2006-02-17 14:59:19
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2006-02-17 15:38:14
@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.

Quote
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

Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: IgorC on 2006-02-17 15:59:12
Quote
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?
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: dimzon on 2006-02-17 15:59:21
Quote
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)
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: IgorC on 2006-02-17 16:00:51
new patched dll is already here. Look  in this topic 
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: dimzon on 2006-02-17 16:07:38
Quote
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
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: IgorC on 2006-02-17 16:09:05
Quote
Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: dimzon on 2006-02-17 16:20:41
Quote
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
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: dimzon on 2006-02-17 16:41:24
@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!
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: IgorC on 2006-02-17 16:59:28
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 .
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Ivan Dimkovic on 2006-02-17 17:25:39
Quote
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

Quote
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.
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: dimzon on 2006-02-17 17:35:15
Quote
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
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: IgorC on 2006-02-17 17:41:03
Seems like We take some extra acitivity 
Title: 48 kbps AAC Encoders Test - Q1 2006 Edition
Post by: Woodinville on 2006-02-17 23:13:10
Try "Just the two of us" by Bill Withers, the first 40 seconds or so. Enjoy the organ.