Nero AAC, listening test :-) Options

[menno]

Yes, everything is affected. I'll make sure Roberto compiles some new compiles.

Menno

[guruboolez]

Thanks.
I used CoolEdit for one practical reason. With faad, I always have problems in ABC/HR : by clicking on the .wav file obtained with faad, there is no sound. And after that, others wave file have problems [i must change the selection, or clickin many time on other A, B or Reference boxes in order to restore sound - and if I click again on the .wav faad file, same problem].

I just try again in order repeat the problem, it immediatly occurs when I decode the mp4 file provided by Ivan Dimkovic. The faad decoder I tried are :
· Faad-based AAC drag'n'drop frontend (>here<
· a faad version bundled with aacenc.zip 2.15 version.

My soundcard : Terratec DMX6fire.

Is that a knwon bug ? Should I enter a parameter in order to decode properly the file ? Where can I find a recent version ?

[menno]

Ok, new CoolEdit filter is now available from RareWares.

I also noticed the problem with playing the files under ABC/HR, I'll have to check what the exact problem is.

Menno

[ak]

I also noticed the problem with playing the files under ABC/HR, I'll have to check what the exact problem is.

There was thread regarding this issue somewhere (WMP doesn't play faad-decoded files).
Something with wav header, IIRC.
I did pair of attempts: decoding mp4 with faad, then opening it with wave editor and saving as ACM waveform:

0000001C: 90 10
0000001D: C0 B1
0000001E: 04 02
0000001F: 0A 00
----------------------
0000001C: 90 10
0000001D: C0 B1
0000001E: A4 02
0000001F: 04 00

This is fc /b faad-decoded against saved by editor (two files).

[guruboolez]

Thanks, it works fine now.
Glad to see that I'm not alone to have this problem with ABC/HR...

[ff123]

Thanks, it works fine now.
Glad to see that I'm not alone to have this problem with ABC/HR...

ABC/HR has a problem with some WAV files which apparently have incorrect information about where the end of the WAV is. The WAV files can be corrected by opening them in a sound editor, slicing a small bit of information from the beginning or end, and saving back to WAV. A future version of ABC/HR should perform a check for such files.

ff123

[rjamorim]

I'm going through a similar problem here. Only the first second of the reference file is played back.

Detail is, if I load the test config and try to play back the reference right away, it plays from start to end.

But if I play a sample first, and then try playing the reference, only a fraction of the first second of it is played.

Here's how my config file looks like:

CODE

TestName = 41_30sec Listening Test

Original = .\Sample01\41_30sec.wav
Sample1  = .\Sample01\41_30sec_1.wav
Sample2  = .\Sample01\41_30sec_2.wav
Sample3  = .\Sample01\41_30sec_3.wav
Sample4  = .\Sample01\41_30sec_4.wav
Sample5  = .\Sample01\41_30sec_5.wav

It doesn't seem like a WAV error to me, since it's played normally at first, and later borks.

Am I doing something wrong?

Thanks for any info.

Regards;

Roberto.

Edit: The reference file has been encoded and later decoded with flac.exe. Is that an issue?
All the samples are decoded from mp4, with FAAD. They play fine.

This post has been edited by rjamorim: Jun 3 2003, 02:06

[ff123]

rjamorim,

Regarding your recent inquiry (2 June 03),

In the situation you describe above, where the sample file seems to break the reference file playback, the issue is that one of the files (I think I remember it being the first one, your sample) does not provide abc/hr with the correct ending time. abc/hr uses an MCI function to look this up. I don't know exactly where this function gets its information, but my guess was that it was in the WAV header.

I need to know how long the WAV files are so that I can do things like offsets properly.

I haven't really tracked the problem down further than that.

ff123

[rjamorim]

I did another test.

This time, I used another sample: ATrain.wav

The same bug occurs. After I listen to one of the samples, the reference file doesn't plays anymore.

Interestingly, I used the reference file (exactly the same file) as sample05. When I try to play back it it plays well - but if I try the reference just after, it borks playback (of the reference only. Sample 5 keeps being playable).

My config file:

CODE

TestName = ATrain Listening Test

Original = .\Sample02\ATrain.wav
Sample1  = .\Sample02\ATrain_1.wav
Sample2  = .\Sample02\ATrain_2.wav
Sample3  = .\Sample02\ATrain_3.wav
Sample4  = .\Sample02\ATrain_4.wav
Sample5  = .\Sample02\ATrain.wav

Therefore, it's surely an issue in ABC/HR. Seems a wav file only borks when it's being used as reference, since this wav file plays perfectly if being used as sample.

Regards;

Roberto.

This post has been edited by rjamorim: Jun 3 2003, 21:48

[ff123]

I did another test.

This time, I used another sample: ATrain.wav

The same bug occurs. After I listen to one of the samples, the reference file doesn't plays anymore.

Interestingly, I used the reference file (exactly the same file) as sample05. When I try to play back it it plays well - but if I try the reference just after, it borks playback.

My config file:

CODE

TestName = ATrain Listening Test

Original = .\Sample02\ATrain.wav
Sample1  = .\Sample02\ATrain_1.wav
Sample2  = .\Sample02\ATrain_2.wav
Sample3  = .\Sample02\ATrain_3.wav
Sample4  = .\Sample02\ATrain_4.wav
Sample5  = .\Sample02\ATrain.wav

Therefore, it's surely an issue in ABC/HR. Seems a wav file only borks when it's being used as reference, since this wav file plays perfectly if being used as sample.

Regards;

Roberto.

I assume you either got ATrain.wav from the zipfile during the 64 kbit/s test or from my samples page, so it hasn't been modified in any way.

I have the zipfile for ATrain saved on my hard drive, so I can reload those files, and then include ATrain.wav as a sample file to try to verify the particular behavior you're describing. But when I was looking at what was going on before, the problem was definitely traced back to the WAV files themselves, with abc/hr being involved because it assumed that the MCI function was returning the correct information from the WAV file.

BTW, the way I remember it was: the first time you play one of those problem files, it will play ok (but it gives abc/hr the wrong end-time information). If you play another file after that, things will be borked. The second file may be ok as a WAV file, even though it doesn't play after things are borked.

ff123

P.S., if you flac and zip your files, and upload them to my site, I can directly verify what you see.

Upload to ff123.net
userid: anonymous@ff123.net
(note: userid must be exactly as shown above, with the @ sign and everything)
use anything as the password, it doesn't matter what
go to the incoming directory and upload to that
you will not get a directory listing when you have finished uploading (a security measure)

[rjamorim]

P.S., if you flac and zip your files, and upload them to my site, I can directly verify what you see.

I am uploading the file now. It's the exact same file I would distribute as part of the test, except that it lacks the readme ATM.

The files should be uncompressed in ABC/HR's dir, and then you should run
Bin/Sample02.bat

Good luck.

Regards;

Roberto.

[ff123]

roberto,

I got your file.

I verified that when I loaded up the five samples, and then added the original as the 6th sample, it worked (or rather it didn't work) just like you said.

Then I made all of the samples the original, and that worked properly. I think I remember that I check the WAV properties of each file prior to each test. That is, I need to know which file will end last, so that I can play this file all the way to the end instead of cutting it off short.

The bottom line is that this behavior is still caused by an WAV file that is different somehow from the typical WAV file.

I opened atrain_1.wav in Cool Edit, and then saved it as a new WAV file, atrain_1a.wav. The old file causes problems, but the new one doesn't. A binary file comparison (using the DOS command "fc") yields the following differences:

Comparing files ATrain_1.wav and ATRAIN_1A.WAV
0000001C: 90 10
0000001D: C0 B1
0000001E: CD 02

I'll look this up to see what the difference is.

ff123

[rjamorim]

Great news, ff123. Thanks a lot for taking a look at it.

So, I believe FLAC is outputting (kinda)bork files? Maybe I should use another lossless format for my test?

[ff123]

Great news, ff123. Thanks a lot for taking a look at it.

So, I believe FLAC is outputting (kinda)bork files? Maybe I should use another lossless format for my test?

No, flac is not at fault here.

The problem appears to be with the FAAD decoded WAV files. The field that is different is the "average bytes per second" field.

I copied the WAV format description to my conv2wav program here:

http://ff123.net/convert/conv2wav.c.txt

If you have the time and energy, maybe you can figure out what FAAD is doing wrong.

ff123

[ff123]

BTW, it looks like that field is redundant, and that it can be calculated assuming that all the other information in the format header is correct. The correct approach is to fix FAAD, but another solution would be to create a small "fixit" program to fix the header. You could run such a program after running FAAD to fix the decoded files. That way you don't have to distribute flac'd wav files -- you could still distribute the much smaller mp4 files.

ff123

[rjamorim]

The problem appears to be with the FAAD decoded WAV files.  The field that is different is the "average bytes per second" field.
[...]
If you have the time and energy, maybe you can figure out what FAAD is doing wrong.

Thanks for the info.

I guess the problem is in this file, somewhere inside the write_wav_header function
http://pessoal.onda.com.br/rjamorim/audio.c.txt

I'll take a look at it, and also ask for Menno's help.

Regards;

Roberto.

[menno]

Hello ff123,

Yes FAAD2 used to have a little bug in the wav file writing, your tool made me aware of that a few months ago. Most other programs seem to play the files just fine (apparantly they don't look at the average bytes per sec).

But of course the problem has already been fixed for a few months

Greetings,

Menno

[rjamorim]

But of course the problem has already been fixed for a few months

Indeed, my compile was dated December

Everything works perfect now.

If there are no more issues, test starts tonight.

[ff123]

If there are no more issues, test starts tonight.

What's this test all about? Obviously I know that it's an AAC test. Is it about Ivan's original request for listening responses or is it something else? Just curious.

ff123

[rjamorim]

What's this test all about?  Obviously I know that it's an AAC test.  Is it about Ivan's original request for listening responses or is it something else?  Just curious.

Since AAC has been getting quite some news coverage lately (Apple, AOL, iRiver...), some people and I thought it would be interesting to do a test to see what codec performs better at 128kbps (whch seems to be a good compromise for portable usage and DSL streaming).

Besides, I plan to take the winner and throw it against Vorbis, Lame, MPC and FhG MP3 in another test. (Maybe including WMA and/or Atrac3 also)

[ff123]

Cool. How many samples are you going to try? Sounds like fun.

[rjamorim]

Cool.  How many samples are you going to try?  Sounds like fun.

I've took your 64kbps test samples.

Then, I replaced BachS1007 and LisztBMinor with death2 and 41_30sec, since some killer samples would be interesting at these bitrates.

So, 12 samples in all. All the packages together will sum to 47Mb worth of downloads.

The sample packages are being uploaded to the server now.

[Tripwire]

If you take WMA9, be sure to use both Std and Pro.

[rjamorim]

If you take WMA9, be sure to use both Std and Pro.

As I understand, there's no difference between them.

WMA pro is just WMA for high bit depths, high sampling rates and multichannel. It isn't even possible to encode a 44100/stereo/16bit sample with it.

[spoon]

How do Codecs with VBR fit in with 128Kbps? to be fair to WMA it should be VBR 2 pass, not that it will win