A suggestion to better design the amount of codecs/samples for the test: Make a poll about how much time would you be willing to spend on the test (for those who would consider participating) and then choose a combination of codecs/samples that best suits the results.
I think all this could be avoided simply by changing the test name from "64 kbps test" to something more like "64kpbs-range test" or "low bitrate test". Some people just take the "64 kpbs" part too much at heart.
Is it worth to put two different anchors in this test ?
For the 128 kbps listening test, anchor was needed to preserve lame mp3 from an exagerate notation. Here, there is no (known) encoder to protect from (known) stronger competitors. Why not remove this one ?
On the other side, I'd like to see mp3@128 as bottom anchor. This anchor is more than a "dead file" : it's a popular reference, and at the end of the test, we can build some conclusions the relation between this file and others competitors. It's very important to give a point of comparison : some people are obnubilate by the idea of mainting 128 kbps quality at half bitrate, and this test, with mp3@128 include, is the occasion to give strong answers (superior to pseudo scientific waveform comparison...) to these people (and it would be a good advertising for HA.org).
Honestly, is a 3.5 Khz lowpassed wav file really needed here ?
That's not a real possibility because, of all the 12 samples, I only have one of them in it's entirety. It would require that people send me the entire songs for each sample. And then I would be accountable for piracy. You get the problem? :B
One idea how to add more codecs to the test would be to make three different test suites. One where wma pro is in, another where real is in but not wma pro, and the third where aac would be in but none of the above. Then when a person downloads the suite, the server randomly gives one of the three packages. This way everybody will test the core codecs but you will still have some results for the additional ones.
Would it be an option to use the 8 sliders for tested codecs only and the higher anchor (lame @128kbps) while the lower anchor (no matter if lowpassed or a crappy encoding) can be provided seperately so people can listen to it without using ABC/HR? It should be so obvious what's wrong compared to the original that ABXing this one isn't necessary - and it'll get a fixed rating (= 1 ?) anyway (if I get the idea of anchors right).
If they don´t upload it here to HA for the public, and yust send the song to you? That´s not piracy, in Germany it´s allowed to make a private copy for realtives and friends (this could have been changed since the new copyright-law).
Another idea is, that they encode the samples themselves, you send them the exact setting (batch-file for CLI-encs), then they decode it again and cut the decoded files and them to you.
I think that´s very important for real-life testing, there have to be a way how it is possible.
For the codecs I think these should be tested:HE-AACmp3proOgg VorbisWMAReal GeckoLame mp3 --preset 128(atrac3plus?)That are 6 (7) codecs, everybody can test that.
dont think that people will get bored if they test 64kbps quality files? hey a 128kbps test were you cant hear any differences is more boring imho
Well, is HE AAC, WMA, and Real even "cuttable"?And, when cutting MP3pro, there's no risk of teh SBR part getting b0rked?
It would be illegal in nearly the entire rest of the World, including Brazil. :-/
Well, it is possible. That's what they do in formal listening tests. But I don't have the resources to conduce a formal listening test (which usually costs 4-digit dollars)
But I noticed something illegal in your old test: You distributed binaries of faad, lame and blade.
Even if you would buy all this discs it would less than 100?/$ (of course even that would be too much).
If the sample owners would encode/cut themselves it would be the easiest and legal way. If you don´t trust them or they are not able to do it alone, you could make own there PCs using NetMeeting remote control.
The codec is named "Gecko" in the real papers, because "Real Audio" can be every codec used by Real (Sipro Voice Codec, DolbyNet, Atrac3 etc.). Because the FourCC of it is "cook" (this comes from the name of the codec developer "Ken Cooke") it also often called so.
Well, I believe few would allow a stranger to remotely control their PCs :B
Well, there I was breaking patents that people don't give much of a damn anyway. It's not nearly as bad as breaking copyright. :-/
And the issue remains: Can we cut MP3pro, AAC+SBR and WMA?
Another issue: If these people were to cut the samples themselves, they would need to own at least Adobe Audition (mp3pro) and Nero 6 (HE AAC). And not all of them own it, and some aren't as morally unrestrained as me as to go and get a ju4r3z version :B
You don´t care about ju4r3z, but you care about copyright???
mp3 aac vorbis wma mpc2.5 4.2 4.0 3.6 4.53.1 4.0 4.3 4.0 5.04.0 5.0 4.2 4.5 5.0
mp3 aac vorbis wma mpc real vqf2.5 4.2 4.0 3.6 4.5 3.1 4.0 4.3 4.0 5.0 3.52.0 3.0 3.2 2.5 3.5 5.0
When are you planning to start the test?
What do you say?
*I think that Guru's idea of 2 sets is interesting but unfortunately probably bad in our case. I am afraid that only experienced listeners would pick the second group. As we know that those listeners are using lower ranking (as demonstrated in the 128kbps test), ranking of both groups would probably not be comparable.
*I am not sure if Atrac-3 is really usefull, considering both the user base and the fact that the new portable players from Sony are now able to use other formats.
*Perhaps plain AAC should be considered, as it is decodable right now by some hardware players, while HE-AAC is not
*If a lower anchor has to be used, why not Lame --preset 64? (mp3 is still widely used at low bitrates for Shout/Ice streaming)
*I think that the high number of codecs is not such an issue, compared to the 128 test. In this case it will be easier for a broad range of listeners.