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: Nero AAC, listening test :-) (Read 21371 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Nero AAC, listening test :-)

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

Menno

Nero AAC, listening test :-)

Reply #26
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 ?

Nero AAC, listening test :-)

Reply #27
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

Nero AAC, listening test :-)

Reply #28
Quote
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:
Quote
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).

Nero AAC, listening test :-)

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

Nero AAC, listening test :-)

Reply #30
Quote
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

Nero AAC, listening test :-)

Reply #31
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: [Select]
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.

Nero AAC, listening test :-)

Reply #32
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

Nero AAC, listening test :-)

Reply #33
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: [Select]
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.

Nero AAC, listening test :-)

Reply #34
Quote
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: [Select]
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)

Nero AAC, listening test :-)

Reply #35
Quote
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.

 

Nero AAC, listening test :-)

Reply #36
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

Nero AAC, listening test :-)

Reply #37
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?

Nero AAC, listening test :-)

Reply #38
Quote
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

Nero AAC, listening test :-)

Reply #39
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

Nero AAC, listening test :-)

Reply #40
Quote
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.

Nero AAC, listening test :-)

Reply #41
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

Nero AAC, listening test :-)

Reply #42
Quote
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.

Nero AAC, listening test :-)

Reply #43
Quote
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

Nero AAC, listening test :-)

Reply #44
Quote
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)

Nero AAC, listening test :-)

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

Nero AAC, listening test :-)

Reply #46
Quote
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.

Nero AAC, listening test :-)

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

Nero AAC, listening test :-)

Reply #48
Quote
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.

Nero AAC, listening test :-)

Reply #49
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