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: 64kbps listening test (Read 47859 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

64kbps listening test

Reply #125
[edit]Removed per rjamorim's post.[/edit]
I am *expanding!*  It is so much *squishy* to *smell* you!  *Campers* are the best!  I have *anticipation* and then what?  Better parties in *the middle* for sure.
http://www.phong.org/

64kbps listening test

Reply #126
Quote
A different set of samples could see them in a much different order.

The order gets even more different if we use a different set of ears
Just wait for, EG, Guruboolez' results.

Anyway, I would like to ask that people don't comment on the test results here, and wait for the results announcement thread, that should be opened in a few hours. That way, comments don't get spread over several threads.

Thanks for your comprehension

Regards;

Roberto.

64kbps listening test

Reply #127
Removed as per Roberto's above post.

64kbps listening test

Reply #128
I just want to comment a moment on the "ease-of-use" of the test materials.  Roberto (and anyone else who helped prepare all of this) are to be commended for the ease with which the test could be executed by us participants.  This was my first involvement in one of the public listening tests, so maybe they've always been this way, but I'm new to all of this.

I was just worried I'd have to do a lot of encoding, test configuration, etc.  It was nice to simply download the start package and samples, then run a batch file and go.  Seamless configuration...an important feature for a newbie like me.   

Thanks Roberto!

64kbps listening test

Reply #129
I'll have to agree with ScorLibran.  Both this test and the 128k test were quite easy to participate in thanks to Roberto's efforts.  Just compare that to the effort required to get a video to play under windows that happens to use the latest and greatest version of whatever-codec-is-cool-this-week.  Thanks!
I am *expanding!*  It is so much *squishy* to *smell* you!  *Campers* are the best!  I have *anticipation* and then what?  Better parties in *the middle* for sure.
http://www.phong.org/

64kbps listening test

Reply #130
Quote
Quote
Knowing Roberto it will be only a few hours into the 22nd of September

My former record, on the 128kbps test, was 3 hours after the closure. I plan to break it this time.

(By having as much as possible ready at the closure time)

No speed record this time : four hours since test closure :/ (I can return to bed )

64kbps listening test

Reply #131
wake up again, the results are here 
I know, that I know nothing (Socrates)


64kbps listening test

Reply #133
An idea to even further simplify things:

You could include wget in the distribution and make batch files that download the sample packages. There could be a "doall.bat" file that downloads all packages and runs the encoding/decoding, but I guess you will create more traffic that way, while not every downloaded sample is put to use.

64kbps listening test

Reply #134
Quote
An idea to even further simplify things:

You could include wget in the distribution and make batch files that download the sample packages. There could be a "doall.bat" file that downloads all packages and runs the encoding/decoding, but I guess you will create more traffic that way, while not every downloaded sample is put to use.

Well, there are lots of issues with that.

First, once the script starts running, you can't stop it anymore. If you do, there's no way to continue from where you left off.

Second, people that are on dial up and want to test only one or two samples would get pissed, because you can only start processing after you finished downloading.

Dial-up adds another issue that is, if the connection goes down at some time, you must restart from zero - again, because you can't restart the batch from where you left off.

And testing such a batch script would be a pain

Thanks for your suggestion but I believe that it's not really feasible

Best regards;

Roberto.

 

64kbps listening test

Reply #135
Quote
First, once the script starts running, you can't stop it anymore. If you do, there's no way to continue from where you left off.

I believe you can ctrl-c out of it. Also wget -c or --continue should make it able to resume the script at any point. Allready downloaded files remain untouched and incomplete ones will be resumed. If all of the encoders/decoders can be set to overwrite the output no matter what, then I think all should be fine. If that is not the case, you could delete all the files that were encoded/decoded before restarting. Granted this would take some more time.
Quote
Second, people that are on dial up and want to test only one or two samples would get pissed, because you can only start processing after you finished downloading.

Agreed. My primary idea was to put the wget stuff in the beginning of each sampleXX.bat. So if a user wants to test sample04 he just has to doubleclick sample04.bat and it will be downloaded for him, extracted to the correct location and all of the encoding/decoding would be done. I thought that the "doall.bat" would only be interesting for broadband users. You could put a warning in the start, something like: "You are about to download 120mb... continue? [Y/N]". My main concern about that is still that you'd be wasting bandwidth with users who will just download everything.
Quote
And testing such a batch script would be a pain

You have a volunteer!
Quote
Thanks for your suggestion but I believe that it's not really feasible

Oh well.  It's not much an issue anyway. I think you can just "wget -i Readme.txt" and it will get every file that is referenced to. Add "-A zip" and it will only download zip files.