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 42393 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

64kbps listening test

Reply #75
Quote
Could you email me a copy as well?  (my email is in the "about" box of abc/hr)

I already uploaded it to RareWares:
http://rarewares.hydrogenaudio.org/files/a.../abchr-java.zip
(Didn't announce it yet)

Worked like a charm on my Win2k

I'll test it later on Linux. Then, I will reupload the abc-hr_bin.zip packages with it and new instructions.

Again, thanks a lot, schnofler.

Regards;

Roberto.

64kbps listening test

Reply #76
Quote
I'm in the process of writing code to "obscure" the config and results files, so when I get that worked out, I'll let you know. But since the code will be freely available, it shouldn't be a problem to duplicate.


I thought about that, too. Encryption of the results files would be a nice feature. I don't know a lot about the subject, but using some asymmetric encryption, where the public key is stored in the config file and the application uses this key to encrypt the results should work fine. The test conductor could then use his private key to decrypt the results files. Hmm, I hope the Java SDK contains some easy to use RSA encryption stuff 

Quote
Looks like I'll also have to add in the looping capability and disabling fast switching as well, so that the applications stay as similar as possible.


Heh, sorry, didn't mean to push you 

Thanks for hosting, Roberto. And glad you could get it to work.

64kbps listening test

Reply #77
Quote
I thought about that, too. Encryption of the results files would be a nice feature. I don't know a lot about the subject, but using some asymmetric encryption, where the public key is stored in the config file and the application uses this key to encrypt the results should work fine. The test conductor could then use his private key to decrypt the results files. Hmm, I hope the Java SDK contains some easy to use RSA encryption stuff

You can have an idea of what have been/is being discussed about encryption usage in ABC/HR here:
http://www.hydrogenaudio.org/forums/index....howtopic=11691&

64kbps listening test

Reply #78
Blah, so much for my Python one.  :-)  Haven't had time to work on it anyway I suppose.
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 #79
Damn. Something didn't work when I tried it on Linux.

But I blame it on my Linux, that is a mess (abusage of apt-get, it seems), and my lack of decent knowledge on this OS.

If anyone is interested, this is the error I got when I ran java -jar abchr.jar

Code: [Select]
Exception in thread "main" java.util.zip.ZipException: error in opening zip file
    at java.util.zip.ZipFile.open(Native Method)
    at java.util.zip.ZipFile.<init>(ZipFile.java:112)
    at java.util.jar.JarFile.<init>(JarFile.java:117)
    at java.util.jar.JarFile.<init>(JarFile.java:55)


I'll upload it with the abchr_bin packages anyway. Hopefully other people out there will be luckier than me.

@danchr: I demand that you try it on MacOS X. Now you have no more excuses to avoid participating.

64kbps listening test

Reply #80
Downloaded the app, and it looks really nice.  That was really quick coding!

A few things I would like to test, or at least know if they have been tested:

1.  Randomization of the samples, both upon loading the files for the first time and when re-starting the test.

2. ABX randomization

3. Accuracy of the results file

4. Do the offsets work properly?

ff123

64kbps listening test

Reply #81
Uploaded his latest version with better error handling. Address is the same.

64kbps listening test

Reply #82
Quote
@danchr: I demand that you try it on MacOS X. Now you have no more excuses to avoid participating.

Do not underestimate the powers of laziness. And studies.

I'll look into it later  (It's 7 AM)

64kbps listening test

Reply #83
Quote
Damn. Something didn't work when I tried it on Linux.

But I blame it on my Linux, that is a mess (abusage of apt-get, it seems), and my lack of decent knowledge on this OS.

If anyone is interested, this is the error I got when I ran java -jar abchr.jar

Code: [Select]
 Exception in thread "main" java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:112)
at java.util.jar.JarFile.<init>(JarFile.java:117)
at java.util.jar.JarFile.<init>(JarFile.java:55)


Well, that looks like Java couldn't even open the jar file. I have no idea what might be causing that, but you could avoid the problem by unzipping the jar file yourself (jar files are just zip files in disguise). If you change to the directory where you unzipped it you should be able to start the program with "java -cp . abchr.Main".

Quote
@danchr: I demand that you try it on MacOS X. Now you have no more excuses to avoid participating.


Actually, I seriously doubt, that it will run on MacOS. That's because of the architecture of the Java Sound API. For one thing, I don't know if there's even an implementation of that API for MacOS (Sun provides Windows and Linux versions only, afaik). And additionally, different implementations can have quite different behaviour. For example, in Sun's reference implementation the only way to output sound is with Sun's software mixer. I can access other mixers (supposedly hardware mixers, since they were named after my sound card), but they seem to be of no use (no output lines can be opened).
In theory, my program does not need Sun's software mixer, but if it doesn't find that mixer, it just grabs the first one available. And if that one is not as generously designed as Sun's mixer (which has almost no constraints on audio formats and buffer size), it is very likely that the program won't be able to play sound.
But nonetheless, if the MacOS implementation of this API is quite similar to Sun's, the program might run without problems, so I really don't want to scare anyone off. Any error (or success) reports would be helpful.

Quote
Downloaded the app, and it looks really nice. That was really quick coding!


Thanks 

Quote
A few things I would like to test, or at least know if they have been tested:

1. Randomization of the samples, both upon loading the files for the first time and when re-starting the test.

2. ABX randomization

3. Accuracy of the results file

4. Do the offsets work properly?


Of course I tested all of this, but simply because of time constraints, I can't be 100% sure that it all works. As for randomization, the samples are randomized when you load a config file, I'm not sure what you mean by "re-starting" (They don't get randomized again when you save a session and load it later, but of course they do get randomized if you load a config file you had loaded before). However, I can remember that there was some debate about the quality of Java's random number generator. I don't know whether that's a thing of the past, so if anyone wants to conduct some randomness-tests, let me know the results 
I'm pretty sure that offsets are working, and I did some serious testing with the results files, but still, any help testing the program is highly appreciated.

64kbps listening test

Reply #84
Ok. i'm running OS X. As of yet, I'm having limited success getting this to work. But that doesn't mean it shouldn't  OK. So, I d/led the 1st sample files (Big yellow) and extracted them as nesscessary. I can't however, open the Sample01.bat file in the ./Bin/ folder. Any tips? What exactly does that file do? Skipping that step, and going into the App, and trying to open the config file, I get a "File.\Sample01\BigYellow.wav could not be found".. So I figure that that is what the .bat files does... Ok... Now...

I open QT, and export a wav file from the QT AAC version of the file, and add that to the directory. The error still occurs. Now I look at it closer.. And I think I see the problem.

Windows uses backslashes (\) for file paths... OS X uses forward slahes  (/)... Soo... Any help?

64kbps listening test

Reply #85
Upon further inspection, the BAT file does exactly that, it converts all the files to WAV. Ok, so this is a DOS Batch file.. so, if the osx binaries were compiled/included for flac, faad, LAME, oggenc (Maybe oggdec?), and the Batch files converted to say shell scripts, then this could still work. Or, if someone had enough Web bandwidth to host all "Uncompressed" files... Just a few thoughts...

64kbps listening test

Reply #86
Quote
Windows uses backslashes (\) for file paths... OS X uses forward slahes  (/)... Soo... Any help?

The same problem occurs on Linux, by the way.

Anyway, to add to the list of working configurations, besides the backslash problem it works well on my setup with RedHat Linux 7.3 and JRE 1.4.1. Kinda makes my own not-yet-released work-in-progress wxWindows/SDL version look like a pile of manure

Cheerio,

Carsten Haese
Ogg Traffic Editor, Xiph.org Foundation

64kbps listening test

Reply #87
Great program! I really like the new keyboard layout in ABX-mode. (w00t)

Some things I noticed:
- You can create comments without changing any rating (not so in ff123's version). They are not saved though, which could lead to some confusion.
- The cursor does not change above the edges of the selected range.
- Default result filename is the name of the config file.

Quote
However, I can remember that there was some debate about the quality of Java's random number generator. I don't know whether that's a thing of the past, so if anyone wants to conduct some randomness-tests, let me know the results

ff123 had a program that could analyze random sequences for their randomness.

Here is a first test I quickly performed:
0 of 1, p = 1.0
0 of 2, p = 1.0
0 of 3, p = 1.0
0 of 4, p = 1.0
0 of 5, p = 1.0
0 of 6, p = 1.0
0 of 7, p = 1.0
0 of 8, p = 1.0
1 of 9, p = 0.998
2 of 10, p = 0.989
3 of 11, p = 0.967
3 of 12, p = 0.98
3 of 13, p = 0.988
4 of 14, p = 0.971
5 of 15, p = 0.94
5 of 16, p = 0.961
5 of 17, p = 0.975
5 of 18, p = 0.984
5 of 19, p = 0.99
5 of 20, p = 0.994

I'm no expert on this, but this doesn't look very random to me .

64kbps listening test

Reply #88
Runs fine under FreeBSD-CURRENT using native Java Development Kit 1.4.1. At least it plays sounds and works basically, haven't stress-tested it yet. Just very slow, well it's Java after all...

The '\' vs '/' could be easily resolved using this simple script:
Code: [Select]
#!/bin/sh
for file in config*txt; do sed -i.bak -e 's|\\|/|g' ${file}; done


The encoding script would be a bit harder. Maybe it would be best to use wine so that we can be sure that the output is the same.

64kbps listening test

Reply #89
Quote
ff123 had a program that could analyze random sequences for their randomness.

Here is a first test I quickly performed:
0 of 1, p = 1.0
0 of 2, p = 1.0
0 of 3, p = 1.0
0 of 4, p = 1.0
0 of 5, p = 1.0
0 of 6, p = 1.0
0 of 7, p = 1.0
0 of 8, p = 1.0
1 of 9, p = 0.998
2 of 10, p = 0.989
3 of 11, p = 0.967
3 of 12, p = 0.98
3 of 13, p = 0.988
4 of 14, p = 0.971
5 of 15, p = 0.94
5 of 16, p = 0.961
5 of 17, p = 0.975
5 of 18, p = 0.984
5 of 19, p = 0.99
5 of 20, p = 0.994

I'm no expert on this, but this doesn't look very random to me .

I used a web-based test for runs to test abchr, I think this one:

http://www.ubmail.ubalt.edu/~harsham/Busin.../Randomness.htm

For Continuum's data, I put a '0' in the web-form if the answer was incorrect, and a '1' if the answer was correct.  I get a p-value of 0.014, which is moderate evidence against randomness, according to that calculator.  Probably more data (how about 80 trials, for example) would give a better picture.

ff123

64kbps listening test

Reply #90
I made two more tests, this time with 80 trials. The first one did look quite random to me, not the other:
7 of 10, p = 0.171
15 of 20, p = 0.02
20 of 30, p = 0.049
25 of 40, p = 0.076
29 of 50, p = 0.161
37 of 60, p = 0.046
41 of 70, p = 0.094
47 of 80, p = 0.072

I entered this in the Web-script. Results:
Number of Runs ( R ): 40
P-value: 0.47916
Conclusion: Little or no real evidences against randomness

I should have stopped at "14 of 18, p = 0.015".

64kbps listening test

Reply #91
First, thanks to everyone for the testing. Nice to know that it runs under Linux, generally.

Quote
Some things I noticed:
- You can create comments without changing any rating (not so in ff123's version). They are not saved though, which could lead to some confusion.
- The cursor does not change above the edges of the selected range.
- Default result filename is the name of the config file.

OK, I resolved all these issues. Any suggestions for a default filename for the results files?

Quote
Runs fine under FreeBSD-CURRENT using native Java Development Kit 1.4.1. At least it plays sounds and works basically, haven't stress-tested it yet. Just very slow, well it's Java after all...

As for the speed, Sun claim they have made performance improvements for Java Sound in 1.4.2. Actually I was rather surprised how well it performed. As you say, it's Java, so of course it eats a lot more memory and is less responsive than ff123's Windows native version. I almost expected fast switching to be totally useless in Java due to latency, but actually the Java Sound API handles this quite well (on my machine, at least).

I also checked on the randomness issues. Actually Sun use a rather common algorithm (linear congruential) for its random number generator. I don't really think they could have messed this up badly, and anyway, I wouldn't know how to improve on the JDK implementation. Suggestions are welcome, of course.

64kbps listening test

Reply #92
I was thinking.. if we could BitTorrent the uncompressed test files (Converted to wav) then we could all use them right? Or do the .bat scripts randomize their order as well?This would be far easier than getting binaries together for all OS's...

64kbps listening test

Reply #93
Quote
The '\' vs '/' could be easily resolved using this simple script:
Code: [Select]
#!/bin/sh
for file in config*txt; do sed -i.bak -e 's|\\|/|g' ${file}; done


The encoding script would be a bit harder. Maybe it would be best to use wine so that we can be sure that the output is the same.

In my next test (whenever that might happen), I plan to work on alternative packages for people running *nix implementations (Linux, Darwin, Solaris, BSD...). That would consist of:

-Bash scripts instead of .bat files
-abchr.jar instead of abchr.exe
-No precompiled binaries of codecs, I would only hope people have mpg123, ogg123, flac, oggenc... on %PATH%.
-tar.gz instead of .zip 

In this test I have just thrown together the .jar in the abc-hr_bin package and hoped people would read the .bat file and sort out some way of doing the processing themselves. On next test it'll be a better thought process :B

Another thing that would be interesting would be that ff123 and schnofler agree on some sort of standard directory separator for the config files, so that there are no more issues of / and \. Of course, that is not really needed if we have one abc-hr package for each OS flavour.

Comments?

Regards;

Roberto.

64kbps listening test

Reply #94
Quote
I was thinking.. if we could BitTorrent the uncompressed test files (Converted to wav) then we could all use them right? Or do the .bat scripts randomize their order as well?This would be far easier than getting binaries together for all OS's...

Bandwidth is not the problem anymore. Spoon has been kind enough to offer me 200Gb of bandwidth, and if that's not enough, Dibrom offered me about 500Gb :B

What keeps me from releasing all samples in lossless is that it would make things too hard for Dial-Up people. A sample package could go well up to 30Mb (even zip-compressed). Multiply it by 12, and you get around 350Mb for a person to download. On 56kbps, it would take well over 30 hours to download everything.

And no, the bat scripts aren't randomizing the order. If they were, there would be no way I could later tell which codec is which. And it would also making processing teh results a nightmare.

64kbps listening test

Reply #95
Let's just write a 'configure' script and hope that people have automake.
ruxvilti'a

64kbps listening test

Reply #96
Quote
Let's just write a 'configure' script and hope that people have automake.

Hehe. You can try that yourself, I don't know that much about scripting.

BTW, I created the batch files following your templates, but couldn't get them to properly be converted to exe. One of the bat2exe tools I tried stopped the process at the middle of the batch, the other generated a GPF on ff123's PC. :B

Could you tell me what tool were you using? Maybe you can also try using it on this test's batches?

Thank-you.

Regards;

Roberto.

64kbps listening test

Reply #97
(thanks for giving me a reason to use HA again  ).

I don't have time to test all 12 samples. From the results you've got so far, are there any particular samples you'd prefer me to concentrate on? I can probably get 4-6 done before Sunday.

64kbps listening test

Reply #98
Well, I'm really anxious to try this test. I happen to have broadband, and there's a good number of people that do to. If bandwidth isn't an issue, I think this would be a great way to get more people involved.

64kbps listening test

Reply #99
Quote
(thanks for giving me a reason to use HA again  ).

I don't have time to test all 12 samples. From the results you've got so far, are there any particular samples you'd prefer me to concentrate on? I can probably get 4-6 done before Sunday.

Not really, whatever sample suits your musical tastes better, maybe

You can find more info about the style of each sample here:
http://www.hydrogenaudio.org/forums/index....showtopic=12358

 
SimplePortal 1.0.0 RC1 © 2008-2021