Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: 48 kbps AAC Encoders Test - Q1 2006 Edition (Read 153775 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

48 kbps AAC Encoders Test - Q1 2006 Edition

Reply #125
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]


[a href="http://www.srcf.ucam.org/~wdhf2/transcoder/]http://www.srcf.ucam.org/~wdhf2/transcoder/[/url]

48 kbps AAC Encoders Test - Q1 2006 Edition

Reply #126
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]

[a href="http://forum.doom9.org/showthread.php?t=102942]http://forum.doom9.org/showthread.php?t=102942[/url]

48 kbps AAC Encoders Test - Q1 2006 Edition

Reply #127
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]


And yet still [a href="http://www.rarewares.org/mediacoder]http://www.rarewares.org/mediacoder[/url]

48 kbps AAC Encoders Test - Q1 2006 Edition

Reply #128
@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)

48 kbps AAC Encoders Test - Q1 2006 Edition

Reply #129
All contenders are now submitted, so let's discuss about samples.
samples discussion

48 kbps AAC Encoders Test - Q1 2006 Edition

Reply #130
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. 

48 kbps AAC Encoders Test - Q1 2006 Edition

Reply #131
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

48 kbps AAC Encoders Test - Q1 2006 Edition

Reply #132
when you use abchr-java, the labels at least can be customized, although the 1-5
scale is not.

ff123

48 kbps AAC Encoders Test - Q1 2006 Edition

Reply #133
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.

48 kbps AAC Encoders Test - Q1 2006 Edition

Reply #134
In reality, you do get a scale that has 50 increments (0 to 5 in tenths).

ff123

48 kbps AAC Encoders Test - Q1 2006 Edition

Reply #135
@ff123 - that is true, you are correct, "dynamic range" of MUSHRA is 2x (not 20x) larger.


48 kbps AAC Encoders Test - Q1 2006 Edition

Reply #137
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.

48 kbps AAC Encoders Test - Q1 2006 Edition

Reply #138
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.

48 kbps AAC Encoders Test - Q1 2006 Edition

Reply #139
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).

48 kbps AAC Encoders Test - Q1 2006 Edition

Reply #140
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.

48 kbps AAC Encoders Test - Q1 2006 Edition

Reply #141
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]

48 kbps AAC Encoders Test - Q1 2006 Edition

Reply #142
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.

48 kbps AAC Encoders Test - Q1 2006 Edition

Reply #143
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.

48 kbps AAC Encoders Test - Q1 2006 Edition

Reply #144
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.

48 kbps AAC Encoders Test - Q1 2006 Edition

Reply #145
Quote
I checked the 48 kbps mode recommended for the test and found no problems/bugs with the bit rate distribution.
[{POST_SNAPBACK}][/a]

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
- "300 kbps" LC

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

48 kbps AAC Encoders Test - Q1 2006 Edition

Reply #146
bug confirmed with Liszt sample...decoding made also with some dshow players and same result pointed by Guru. (only silence)

48 kbps AAC Encoders Test - Q1 2006 Edition

Reply #147
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. Will this test be postponed? Or will an exception be made?

48 kbps AAC Encoders Test - Q1 2006 Edition

Reply #148
I also subbmited another problematic sample http://www.mytempdir.com/456921 before. I thought bug is produced only here. But I tested on  other PC. The same result.

48 kbps AAC Encoders Test - Q1 2006 Edition

Reply #149
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.