64 kbps listening test 2005, Pre-test thread Options

[rjamorim]

I have a working SS installation if that matters.

Oh, yes, after I reinstalled my system from scratch it installed without problems. But it is (was?) a terrible buggy program, neverthless.

I think it's somewhat related to the security and encryption crap Sony installs everywhere.

[Gabriel]

Might be usefull to do the SonicStage installation under VMWare or something similar.

[Latexxx]

I can prepare the samples if required.

[bond]

what are the up- and downsides of the differen vorbis version, which could be used?

I would take Sony's Atrac3plus @ 64 kbps. It has shown some potential with non-problem samples and it would be great to compare it to other formats.

i would also love to see atrac3+ to be tested

and if there is space for another codec, apple lc-aac would be interesting too

[rjamorim]

and if there is space for another codec, apple lc-aac would be interesting too

I don't think so. Who uses LC AAC at such bitrates, if one can use HE AAC with much better quality?

[bond]

I don't think so. Who uses LC AAC at such bitrates, if one can use HE AAC with much better quality?

it would show the quality difference between he-aac and lc-aac at such a bitrate

well, just realised that we already tested that in your 64kbps test

[rjamorim]

well, just realised that we already tested that in your 64kbps test 

Exactly

I don't think the gap got much different since.

[Gabriel]

Who uses LC AAC at such bitrates, if one can use HE AAC with much better quality?

Nokia users who did not replaced the tinny memory card they got with the phone?

[Eli]

I would be interested in seeing MPC in the test. I know its not tuned for these bit rates but it did suprisingly well at 128 and Im hoping that the new team does some tuning at low bit rates after work on 7.5 or 8 is well underway. While it currently has littly hardware support, its low CPU overhead for decoding could help extend battery life on flash players where decoding is the major drain on batteries.

[rjamorim]

I would be interested in seeing MPC in the test. I know its not tuned for these bit rates but it did suprisingly well at 128 and Im hoping that the new team does some tuning at low bit rates after work on 7.5 or 8 is well underway. While it currently has littly hardware support, its low CPU overhead for decoding could help extend battery life on flash players where decoding is the major drain on batteries.

As you said yourself, it's badly tuned at these bitrates, so I don't see what is the point of such test currently.

Maybe if the dev team really tunes low bitrates after SV8 is released, then that might warrant a new test.

This post has been edited by rjamorim: Mar 22 2005, 17:58

[Sebastian Mares]

OK... So far, MusePack and LC AAC will definitely not be included in the test. MusePack isn't the encoder to test at 64 kbps, the same applies to LC AAC.

MusePack's emphasis is on quality and transparency and was never designed for such low bitrates. People using MusePack will at least encode at 128 kbps. As Roberto already stated, if things change after SV8, MusePack should be included in a 64 kbps listening test.

As for LC AAC, I doubt that there are any major improvements since the last 64 kbps test (where Apple's implementation was used) and for such a low bitrate, it is logical to use HE-AAC. Also, I think it's a good idea to have a direct comparision between Nero HE-AAC and Apple HE-AAC and that makes AAC appear twice in the test.

This post has been edited by Sebastian Mares: Mar 22 2005, 18:18

[mickywicky]

If you mean preparing samples, it is pretty easy nowadays using a program called himdrenderer.

Ah, that's good news, indeed. But he'll still have to install SonicStage. That flaming piece of poo ruined my win2000 installation.

That is certifiable bollocks. Hardware encoding has no reason to be better than software encoding, quite the opposite: hardware encoding faces limitations related to battery consumption, real-time processing on underpowered DSPs, integer-only processing, etc, etc.

I have a working SS installation if that matters.

There are some hardware atrac3 vs SS atrac3 abx threads somewhere.

Hmm yeah but either way, do those MD fanboys conclude all recording/copying/converting shoudl be done by the device rather than a PC??
Don't get me wrong, I have an MD player (old school model from 1996 or so) and I quite like it. It was very good back then too. And I did most of the copying using the device itself. Two words: *big hassle*.
I don't think most MD users would do that if they were given the alternative.
So, even if we asume that hardware encoding is better, that we really should use software encoding (there are hardware MP3 encoders too, after all) - at least until ABX tests prove there is a noticeable difference.

[SirGrey]

Vote for atrac3+ and wma std.
WMA pro would be more interesting but less useful

[sehested]

Vote for Atrac3+

I would like to suggest the following sample for the listening test:

Supertramp - School

The 19s sample I have uploaded contains acoustic guitars, piano, cymbals and bass.

I have good experience with this sample in revealing subtle difference between encodings.

Let me hear what you think about the sample.

If desired I can upload a 30s version of the sample.

[Gabriel]

Sample proposition: the beginning of "Money" by Pink Floyd.

I do not have it available, but I am sure some Pink Floyd fan could upload it.
Basically it is background music with coins and cash machine sounds. I think that the coins coud be interesting.

[Sebastian Mares]

Sample proposition: the beginning of "Money" by Pink Floyd.

I do not have it available, but I am sure some Pink Floyd fan could upload it.
Basically it is background music with coins and cash machine sounds. I think that the coins coud be interesting.

Yeah, I can... The clipped remastered version or the "old" one?

[rjamorim]

Yeah, I can... The clipped remastered version or the "old" one?

SHINE ON

[Gecko]

I think it would be interesting to use the SSE optimized aotuvb3/archer version of Ogg Vorbis.

A direct comparison to the non SSE version would be best, but since differences are expected to be small anyway, this is an opportunity to test it on multiple samples. If any problems come up, it could be tested against the regular version after the test.

Of course if you want to do the encoding at the user end, you'll have to distribute separate versions of the sample packages for people with non SSE capable CPUs.

[rjamorim]

The problem in using Archer and aotuv3, IMO, is that the results won't be as valid as we would like them to be. If vorbis performs badly, we'll not know if it is becauseof a format weakness or just because the tweaking broke something. After all, these are beta versions - not for production environments.

Now, IF the Vorbis fellas around here conduce a little test before the real thing, like happened in my multiformat @ 128 test, then the choice of what version to use will be supported by more reasons than just "let's give it a try".

[Eli]

I would be interested in seeing MPC in the test. I know its not tuned for these bit rates but it did suprisingly well at 128 and Im hoping that the new team does some tuning at low bit rates after work on 7.5 or 8 is well underway. While it currently has littly hardware support, its low CPU overhead for decoding could help extend battery life on flash players where decoding is the major drain on batteries.

As you said yourself, it's badly tuned at these bitrates, so I don't see what is the point of such test currently.

Maybe if the dev team really tunes low bitrates after SV8 is released, then that might warrant a new test.

Well, it wasnt really tuned for 128 either was it and it is tied for first

[S_O]

Nero HE-AAC and Apple HE-AAC (has it already been released??) are tested, what about FhG / Coding Technologies HE-AAC? It is the only HE-AAC implementation available for free (in Helix Producer). I think it should be included.

[Gecko]

The problem in using Archer and aotuv3, IMO, is that the results won't be as valid as we would like them to be. If vorbis performs badly, we'll not know if it is becauseof a format weakness or just because the tweaking broke something. After all, these are beta versions - not for production environments.

Now, IF the Vorbis fellas around here conduce a little test before the real thing, like happened in my multiformat @ 128 test, then the choice of what version to use will be supported by more reasons than just "let's give it a try".

You're right. But I believe the differences regular/SSE would be minimal and this may be a chance to detect flaws (I don't expect any that result from the optimizations). This could be verified after the test by checking the problem cases against the regular version.

But if you need to run a separate test anyway then you might as well do it beforehand. Maybe there are serious flaws which could ruin Vorbis' reputation!

The archer tunings are at RC3 right now and I think we will see a final soon. Ah, but of course the archer tunings will still remain beta, my bad.

edit: added quote

This post has been edited by Gecko: Mar 23 2005, 00:28

[kurtnoise]

Nero HE-AAC and Apple HE-AAC (has it already been released??) are tested, what about FhG / Coding Technologies HE-AAC? It is the only HE-AAC implementation available for free (in Helix Producer). I think it should be included.

The HE-AAC encoder from Helix Producer hasn't been improve since last 64kbps listening tests. There is only new thing : introduction of new target bitrates (32 & 48 kbps).

[Gecko]

Well, it wasnt really tuned for 128 either was it and it is tied for first

I just tried it on one sample at quality 1 and 2. MPC is not a contender at this bitrate. Sounds like you are underwater, bubbles everywhere - great effect. In comparison, Lame encoded at 64k is hifi. No ABX required.

[sehested]

I have two more candiates for listening test samples...

They are both exceptionally well mastered using the Blumlein technique where the entire sound picture is captured at a single point, carefully chosen to achieve the optimum balance between direct sound and reverberation.

This makes unnecessary all forms of electronic correction and manipulation and the music signal travels by the absolutely shortest possible path between the microphone and the final CD.

The first sample is recorded in an old stone church:

Vaquero

The second sample is recorded in a jazz club:

Four Brothers

What's unussual with these recordings is their depth of image, timbre and dynamics.

For more info on the recording:

Opus3 Recordings