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: New experimental version of aoTuV (Read 14884 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

New experimental version of aoTuV

Reply #1
I'm trying to decipher what has changed.  This is based on 1.1rc.
The ATH(?) table has some changed values, as has the psy data tables, and there is some added code that does 'Dynamic impulse block noise control' and some other changes to short block selection which is probably related.

I haven't actually tried listening to it yet. 

New experimental version of aoTuV

Reply #2
Quote
aoTuV experiment [20040815]

The differences from the aoTuV beta 2 and Vorbis 1.1 RC1...

  Dynamic impulse block noise control(q0-10 & 32/44.1/48kHz).
  New ATH curve.

...and Various tunings.



There is no q-2 mode of aoTuV beta2 in this version.
It applies to Vorbis 1.1 RC1 correspondingly.



by Aoyumi

New experimental version of aoTuV

Reply #3
how can I test this encoder?

when I use it by commandline it says "sourcefile not found"
the same with multifrontend.

it crashes with EAC, Foobar and Universial Frontend.

New experimental version of aoTuV

Reply #4
now it says Encoding... with the following commandline:
C:\Eac\encoder.exe -q2 track01.wav
but it aborts after one second!?

the older encoder.exe (aoTuV b2) works fine with this commandline. And even the older binaries work fine. Why does the new encoder not work with the same commandline?

New experimental version of aoTuV

Reply #5
It's definitely an experimental executable and it isn't suited as a full replacement for oggenc. It doesn't work unless you get rid of the space between "-q" and the quality integer. As for the aborting behavior, I didn't encounter that problem but I put the input filename in quotes.

New experimental version of aoTuV

Reply #6
Quote
now it says Encoding... with the following commandline:
C:\Eac\encoder.exe -q2 track01.wav
but it aborts after one second!?

the older encoder.exe (aoTuV b2) works fine with this commandline. And even the older binaries work fine. Why does the new encoder not work with the same commandline?
[a href="index.php?act=findpost&pid=234861"][{POST_SNAPBACK}][/a]

DeeZi, could you upload the sample that you failed to encode? Aoyumi introduced some experimental code to improve short blocks. I hear it crashes on some environments or samples, but I've never met before. 

OggEnc version of this tuning will be released soon. But  please keep in mind that this tuning is in the early stage.

New experimental version of aoTuV

Reply #7
The new build doesn't work with any of the switches I have tested.
It crashes after only 1 Second with every sample. I always have 0kb output .wav files!

the other and older experimental versions from aoyumi work fine with every sample and commanline.

It seems that I have to wait for a new Oggenc version with this experimental code.


New experimental version of aoTuV

Reply #9
Hello, guys.

Today, I could have some spare time to test latest version of aoTuV. And here's the result.

I actually prefer the new version on this sample probably because of its sharper transients.

211kbps(1.1RC1 -q6) vs 219kbps (aoTuV exp. 20040815 -q6)

Code: [Select]
-------------------------------------
WinABX v0.42 test report
08/20/2004 16:03:39

A file: I:\test\castanets\castanets.wav
B file: I:\test\castanets\aotuv040815q6.wav

16:04:24    1/1  p=50.0%
16:05:38    2/2  p=25.0%
16:05:46    3/3  p=12.5%
16:06:53    4/4  p=6.2%
16:08:10    5/5  p=3.1%
16:08:22    6/6  p=1.6%
16:08:27    7/7  p=0.8%
16:08:38    8/8  p=0.4%
16:08:44    9/9  p=0.2%
16:08:51  10/10  p< 0.1%
16:08:53  test finished

-------------------------------------
WinABX v0.42 test report
08/20/2004 16:11:10

A file: I:\test\castanets\1.1rc1q6.wav
B file: I:\test\castanets\aotuv040815q6.wav

Start position 00:02.0, end position 00:03.3
16:11:54    1/1  p=50.0%
16:12:01    1/2  p=75.0%
16:12:16    2/3  p=50.0%
16:12:29    3/4  p=31.2%
16:12:38    4/5  p=18.8%
16:12:52    5/6  p=10.9%
16:13:02    6/7  p=6.2%
16:13:33    7/8  p=3.5%
16:13:39    7/9  p=9.0%
16:14:02   7/10  p=17.2%
16:14:10   8/11  p=11.3%
16:14:50   8/12  p=19.4%
16:15:00   9/13  p=13.3%
16:15:06  10/14  p=9.0%
16:15:18  11/15  p=5.9%
16:15:28  11/16  p=10.5%
16:15:34  11/17  p=16.6%
16:15:39  12/18  p=11.9%
16:16:00  12/19  p=18.0%
16:16:05  13/20  p=13.2%
16:16:14  13/21  p=19.2%
16:16:22  14/22  p=14.3%
16:16:29  15/23  p=10.5%
16:16:37  16/24  p=7.6%
16:16:45  17/25  p=5.4%
16:16:59  18/26  p=3.8%
16:17:01  test finished

New experimental version of aoTuV

Reply #10
Wow, I found a pretty substantial bug in this version. The stereo can get all messed up. Sometimes the channels get switched: left becomes right and vice versa. I'll upload a WAV file (The Bats - Silverbeet - 13 - Half Way To Nowhere) where the problem is very obvious.

New experimental version of aoTuV

Reply #11
In Audacity I looked at the WAV and Ogg file I mentioned above. It appears that the channels are completely switched for the entire file. I picked another WAV and Ogg combination (from the same album) and the channels matched OK. So my initial guess is that some initialization value gets set wrong under some circumstances.

I encoded the problem WAV in 1.1RC1, megamix1/2 and auToV b2 and there were no stereo problems. So it's limited to this experimental version only.

New experimental version of aoTuV

Reply #12
Hmmm, this is going to be hard to validate. When I took a sample in the middle of the WAV the problem went away. I even tried taking a sample from the very beginning but the stereo issue was gone. So at this point you'll have to take my word on it that this version can switch the stereo channels during encoding, though it does seem rare.

New experimental version of aoTuV

Reply #13
@mithrandir

I have not heard a stereo-related problem (comparing with 1.1 RC1 or aoTuV beta2). In order to clarify a cause, the sample which causes a problem is required.

And please try "aoTuV experiment [20040810]".

New experimental version of aoTuV

Reply #14
I'm "afraid" I sounded a false alarm. aoTuV didn't create the problem.

I don't know how this happened but apparently one of the WAV files that I used for testing had the channels switched and I used aoTuV on a corrected WAV that I ripped on a different machine. I'm still confused on how this happened but after going through all the iteratioms I've now confirmed that the experimental aoTuV encoder is not problematic...please ignore my earlier posts.

New experimental version of aoTuV

Reply #15
It seems that aoTuV (and perhaps other third party tunings) will become the main focal point of Vorbis tuning improvements with Monty now taking on the management role of Executive Director and no-one at Xiph.Org to do any coding.

New experimental version of aoTuV

Reply #16
It's better than nothing  (afterall, the last major improvments done by XIPH's coders are dated from july 2002).

I'm still waiting for a vorbis encoder free of hiss/coarseness beyond ~112...128 kbps. I've quickly tried the experimental tuning (august) of aoTuV, and I couldn't detect any regression of this problem :/
Wavpack Hybrid: one encoder for all scenarios
WavPack -c4.5hx6 (44100Hz & 48000Hz) ≈ 390 kbps + correction file
WavPack -c4hx6 (96000Hz) ≈ 768 kbps + correction file
WavPack -h (SACD & DSD) ≈ 2400 kbps at 2.8224 MHz

New experimental version of aoTuV

Reply #17
Quote
It seems that aoTuV (and perhaps other third party tunings) will become the main focal point of Vorbis tuning improvements with Monty now taking on the management role of Executive Director and no-one at Xiph.Org to do any coding.
[a href="index.php?act=findpost&pid=239746"][{POST_SNAPBACK}][/a]


I don't understand that. So even Monty will now stop coding and all projects will be halted? (since he seems to be the only active coder there...)

I miss the days of Emmett. He might have his flaws (being a die-hard zealot is the first that comes to mind), but at least back then things were much more interesting.

New experimental version of aoTuV

Reply #18
I guess I need more training because I can't hear any hiss/coarseness in Vorbis at a reasonable bitrate.  Vorbis nowadays is for me pretty much transparent.  I also completely lack the ability to hear preecho at all as i cannot ABX castanets at even -q0.  I view it as a blessing though 

It's a shame that Xiph diverts pretty much all of their attention away from Vorbis as it is their most used codec.  Thankfully third party tuners exist but their work doesn't really reach the masses (compared to Xiph.org versions).
Nero AAC 1.5.1.0: -q0.45

New experimental version of aoTuV

Reply #19
Quote
I guess I need more training because I can't hear any hiss/coarseness in Vorbis at a reasonable bitrate.  Vorbis nowadays is for me pretty much transparent.  I also completely lack the ability to hear preecho at all as i cannot ABX castanets at even -q0.  I view it as a blessing though 


I think the hiss and coarseness is most apparent in classical music, where Vorbis is very weak.

As for me, I've got very little time these days to implement some ideas I've had for a while.  Need to get my dissertation out of the way before I can get back into some Vorbis experimentation.  Thankfully we have Aoyumi and Nyaochi

guruboolez:

With regards to the coarseness you describe, are they similar to the effects you hear when listening to SBR?

New experimental version of aoTuV

Reply #20
No, completely different. Simple description: vorbis introduces noise, whereas SBR general artifacts are closer to a grainy or sandy texture (on tonal material).

The coarseness issue is not really specific to classical music. It's also audible with metal (but probably less at high bitrate, in the -q5...5,99 area).
Wavpack Hybrid: one encoder for all scenarios
WavPack -c4.5hx6 (44100Hz & 48000Hz) ≈ 390 kbps + correction file
WavPack -c4hx6 (96000Hz) ≈ 768 kbps + correction file
WavPack -h (SACD & DSD) ≈ 2400 kbps at 2.8224 MHz

New experimental version of aoTuV

Reply #21
Quote
No, completely different. Simple description: vorbis introduces noise, whereas SBR general artifacts are closer to a grainy or sandy texture (on tonal material).


Ah ok, thanks.  I was curious because I remember you mentioned something about grainy noise with Vorbis (before aoTuV beta 2) on instruments that were highly tonal like the cello.

New experimental version of aoTuV

Reply #22
Cello are sometimes encoded with a lot of ringing, which could sound as something close to "grain". I can't see another explanation (if you have an exact link, I could be more precise).
SBR problems are very typical (I've noticed them on mp3pro long time ago, and found them again when the first he-aac encoder was released last summer).
Wavpack Hybrid: one encoder for all scenarios
WavPack -c4.5hx6 (44100Hz & 48000Hz) ≈ 390 kbps + correction file
WavPack -c4hx6 (96000Hz) ≈ 768 kbps + correction file
WavPack -h (SACD & DSD) ≈ 2400 kbps at 2.8224 MHz

New experimental version of aoTuV

Reply #23
You can easily hear this noise issue by generating a tone in Audicity and then encoding the resulting WAV with Vorbis. Interestingly enough the noise signature doesn't change much from -q 0 to -q 10. The same tones generally pass with flying colors using MPC.

New experimental version of aoTuV

Reply #24
Quote
The coarseness issue is not really specific to classical music. It's also audible with metal (but probably less at high bitrate, in the -q5...5,99 area).

I think that this problem is in block switching.
For example, this of the noise of brass is just the cause.

Probably, in the present block switching algorithm, it will be difficult to solve this problem without increase of the bit rate.


Quote
You can easily hear this noise issue by generating a tone in Audicity and then encoding the resulting WAV with Vorbis.

Sine wave?
Would you upload a sample, if very well?