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: aoTuV pre-beta 5 released! (Read 114541 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

aoTuV pre-beta 5 released!

Reply #1 –
Good news!
Code: [Select]
c:\Temp>oggenc2.exe -q-1 -o fortuna2.ogg fortuna.wav
Skipping chunk of type "fact", length 4
Opening with wav module: WAV file reader
Encoding "fortuna.wav" to
         "fortuna2.ogg"
at quality -1,00
        [ 96,0%] [ 0m00s remaining] -

Done encoding file "fortuna2.ogg"

        File length:  0m 21,0s
        Elapsed time: 0m 03,1s
        Rate:         7,0737
        Average bitrate: 48,1 kb/s


c:\Temp>venc.exe -q-1 fortuna.wav
aoTuV - Ogg Vorbis Encoder
[2ch/44.1kHz/16bit WAV file]
 Quality -1 (nominal bitrate : 48kbps)
 Encoding...Done.

[status]
  long  : 457block(96.24%)
  short : 143block(3.76%)

aoTuV 4.51 -q-1 - 48kbps
aoTuv pre-beta 5 -q-1 - 50kbps
...

aoTuV pre-beta 5 released!

Reply #2 –
What does it mean ?

aoTuV pre-beta 5 released!

Reply #3 –
It probably means more bits are allocated to slightly improve quality at that given nominal bitrate (or quality) compared to the previous tuning.

aoTuV pre-beta 5 released!

Reply #4 –
Yeah, you'd have to compare how they actually sound for a similar-bitrate comparison to be meaningful... or you'd have to compare the bitrate for a similar-quality comparison to be meaningful.

aoTuV pre-beta 5 released!

Reply #5 –
Just to be sure everyone has seen it :

Quote
aoTuV pre-beta5 [20060321]  Win32 reference binary
# Quality -1 only.

aoTuV pre-beta 5 released!

Reply #6 –
This version includes change which improves the problem by noise normalization and channel coupling.
Although I recognize it as there being no big problem as a result of many tests, please announce, if you found the peculiar problem of this test version. 

aoTuV pre-beta 5 released!

Reply #7 –
Awesome!  I am actually at this very moment in the process of encoding my lossless material to ogg q-2, but I'm finding it doesn't sound quite good enough.  With new optimizations to q-1 I could use that and probably get very satisfactory sound.

Just a question though (hopefully not too offtopic) - Would I get significantly better encoding results at ogg q-1 by downmixing to mono, and/or resampling?  Or does the codec already do things like this?

aoTuV pre-beta 5 released!

Reply #8 –
Quote
Just a question though (hopefully not too offtopic) - Would I get significantly better encoding results at ogg q-1 by downmixing to mono, and/or resampling? Or does the codec already do things like this?

Encoder will automatically change to suitable sampling rate, stereo coupling depending on bitrate you choose.


It's quite hard for me to tell pre-beta5 from 4.51.
The same kind of encoder has many resemblance, and it's much difficult to test even at low bitrate.
This sample is distorted in first 1second compared with 4.51. Same issue with sample17 used in 48kbps AAC 2006 test.

aoTuV pre-beta 5 released!

Reply #9 –
Quote
Encoder will automatically change to suitable sampling rate, stereo coupling depending on bitrate you choose.

The encoder won't change the sampling rate according to bitrate, though it will change the lowpass (I'd rather put my trust in a SSRC resampling than a brutal lowpass, YMMV).  Also, the encoder's low-bitrate choice of stereo coupling isn't the same thing as downmixing to mono, but there's not much comparative bitrate win in encoding pre-downmixed mono sources versus stereo at these low bitrates anyway IIRC.

aoTuV pre-beta 5 released!

Reply #10 –
How about the Quality at high bitrates? such as Q8-10
I always use them as my foobar , treat as a semi-lossless format
mostly used on classical (Frequency of classic is very wide , may over ~21KH?Z)
so it is a good news if the quality can be increased

I can afford very high bitrate

aoTuV pre-beta 5 released!

Reply #11 –
Quote
How about the Quality at high bitrates? such as Q8-10
I always use them as my foobar , treat as a semi-lossless format
mostly used on classical (Frequency of classic is very wide , may over ~21KH?Z)
so it is a good news if the quality can be increased

I can afford very high bitrate
[a href="index.php?act=findpost&pid=374662"][{POST_SNAPBACK}][/a]


Quote
Just to be sure everyone has seen it :
Quote

aoTuV pre-beta5 [20060321]  Win32 reference binary
# Quality -1 only.

aoTuV pre-beta 5 released!

Reply #12 –
Quote
Just a question though (hopefully not too offtopic) - Would I get significantly better encoding results at ogg q-1 by downmixing to mono, and/or resampling?  Or does the codec already do things like this?
[{POST_SNAPBACK}][/a]

No.

Quote
It's quite hard for me to tell pre-beta5 from 4.51.
The same kind of encoder has many resemblance, and it's much difficult to test even at low bitrate.

Please listen to quiet music.

Quote
[a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=42866]This sample[/url] is distorted in first 1second compared with 4.51. Same issue with sample17 used in 48kbps AAC 2006 test.

OK, I will check.

aoTuV pre-beta 5 released!

Reply #13 –
Thanks for the reply Aoyumi, but that was a tad ambiguous... you mean no to the first part of the question right?  As in I would not get better results by downmixing and or resampling, so there's no point.

I'll assume this if you don't reply.

aoTuV pre-beta 5 released!

Reply #14 –
Quote
Thanks for the reply Aoyumi, but that was a tad ambiguous... you mean no to the first part of the question right? As in I would not get better results by downmixing and or resampling, so there's no point.
I think that he mean no to the second question... because AFAIK you will get better results using mono than stereo (and/or resampling) sice it encode only one channel and use all the bitrate for that channel and not for both... thats hypotheticaly speaking sice you will lost the stereo and if resampling lost the high frequencies and probably only valid for low bitrates.

AND is no to the second because if you don't said to the encoder that you want mono or that you want resampling, it will use the the same as input.

But you are waiting the reply of Aoyumi, so I think that mine is useless.
JorSol
aoTuVb5 -q4

aoTuV pre-beta 5 released!

Reply #15 –
Quote
Quote
How about the Quality at high bitrates? such as Q8-10
I always use them as my foobar , treat as a semi-lossless format
mostly used on classical (Frequency of classic is very wide , may over ~21KH?Z)
so it is a good news if the quality can be increased

I can afford very high bitrate
[a href="index.php?act=findpost&pid=374662"][{POST_SNAPBACK}][/a]


Quote
Just to be sure everyone has seen it :
Quote

aoTuV pre-beta5 [20060321]  Win32 reference binary
# Quality -1 only.


[a href="index.php?act=findpost&pid=374666"][{POST_SNAPBACK}][/a]



I mean that the if the quality of high bitrate can improved in beta 5, vorbis will be more prefect, now i am using b 4.51

aoTuV pre-beta 5 released!

Reply #16 –
Quote
I mean that the if the quality of high bitrate can improved in beta 5, vorbis will be more prefect, now i am using b 4.51
It's almost imposible (for me at least) to tell the diference using quality 6 and up... so vorbis need to improve the low bitrate to be more perfect...

I know that there is a big diference in size compared to lossless... but if the space is no problem (If you can afford very high bitrate) then I recommend using a lossless codec and not use vorbis as "semi-lossless"...
JorSol
aoTuVb5 -q4

aoTuV pre-beta 5 released!

Reply #17 –
As for semi-lossless, I once started a thread here: http://www.hydrogenaudio.org/forums/index....topic=32651&hl=

In it, I discussed the concept of designing a "quasi-lossless" codec that did not use a human perceptual model for lossy encoding, the intention being to have a codec that gets smaller-than-lossless files, but transcodes almost transparently compared to lossless.

I discovered that WavPack hybrid mode almost achieves this, and at somewhere between 384-420 kbit/s, which is probably less than half of what you get with lossless for most popular music. (but speech, classical is already very low-bitrate with lossless codecs).

So in short, I'd recomment WavPack lossy at 400 Kbit/s if you want a "semi-lossless" mode, and your intention is to transcode to smaller files, like for a DAP, at a later time.

aoTuV pre-beta 5 released!

Reply #18 –
Quote
(already asked, i know...)

Expecially for low bitrates seems to be useful to apply a DC offset correction...

Here are some interesting links:

Sure-Fire Tips for Encoding High-Quality, Low-Bandwidth Audio, Part 1
Sure-Fire Tips for Encoding High-Quality, Low-Bandwidth Audio, Part 2
RealNetworks' Signal Processing

So why not integrate it ?

It could be also interesting to implement some type of "advanced stereo2mono" conversion algorithm, expecially for streaming (webradios, etc)...

FlatStereo for example...


SSRC integration would be great too !!! 
(note: I know is already done into RareWares' Oggenc builds, but WE wanna use the Lancer builds too  )

aoTuV pre-beta 5 released!

Reply #19 –
Quote
Thanks for the reply Aoyumi, but that was a tad ambiguous... you mean no to the first part of the question right?  As in I would not get better results by downmixing and or resampling, so there's no point.
[a href="index.php?act=findpost&pid=374864"][{POST_SNAPBACK}][/a]


Since the present Vorbis encoder is a quality base, even if it performs "downmix" and/or "resample", quality does not necessarily become good. Instead, the bit rate falls.

If it is the bit rate same, of course, a possibility of becoming better is high (it is not 100%).

aoTuV pre-beta 5 released!

Reply #20 –
Let encoder choose whatever about quality setting.

Encoder will change sampling rate, if necessary, like LAME.
aoTuV does not, because it does not need to.

I did some comparison with/without SSRC(resample to 32kHz), and encoded sample without resampling was better.
(aoTuV 4.51 -q -1)

aoTuV pre-beta 5 released!

Reply #21 –
Quote
Let encoder choose whatever about quality setting.

Encoder will change sampling rate, if necessary, like LAME.
aoTuV does not, because it does not need to.

I did some comparison with/without SSRC(resample to 32kHz), and encoded sample without resampling was better.
(aoTuV 4.51 -q -1)
[a href="index.php?act=findpost&pid=375113"][{POST_SNAPBACK}][/a]

You need to increase the quality setting for getting the same target bitrate and making the comparison fair.

I have found that for 32 Khz files the correct setting for 48 kbps target bitrate is -0.55.


Edit

Besides, the usual rules are valid also with low bitrate testing. I think you should provide ABX logs, detailed information about the test procedure and a sample file (or files) before making claims. Otherwise no one can try to properly reproduce your findings.

aoTuV pre-beta 5 released!

Reply #22 –
Of course I'm sure about bitrate.

I tested 18sample from Gabriel's 48kbps AAC public test.
The differences of birate was only 3kbps.

I think it is fair comparison.

Quote
I have found that for 32 Khz files the correct setting for 48 kbps target bitrate is -0.55.
How did you conclude the value.

aoTuV pre-beta 5 released!

Reply #23 –
Quote
I did some comparison with/without SSRC(resample to 32kHz), and encoded sample without resampling was better.
(aoTuV 4.51 -q -1)
better how?

one thing you have to keep in mind when using different sample rates is the different lowpass frequencies.. see here for the table..
http://www.hydrogenaudio.org/forums/index....ndpost&p=357461

at 44100hz -q-1 the lowpass is 14.8khz
at 32000hz -q-1 the lowpass is 12.6khz.. even at q0 the lowpass is still lower (13khz)

perhaps this difference could be the reason that your non-resampled sample sounded 'better' to you?
Vorbis-q0-lowpass99
lame3.93.1-q5-V9-k-nspsytune

aoTuV pre-beta 5 released!

Reply #24 –
Quote
Quote
I have found that for 32 Khz files the correct setting for 48 kbps target bitrate is -0.55.
How did you conclude the value.
[{POST_SNAPBACK}][/a]

The file header shows that information. I found the correct value by testing several different settings.

This is what foobar tells about a 32 kHz aoTuV b4.51 -q-0.55 file:
Quote
bitrate = 46
channels = 2
samplerate = 32000
bitrate_nominal = 48
codec = Vorbis
vorbis_vendor = AO; aoTuV b4b [20051117] (based on Xiph.Org's libVorbis)

Also, e.g. Mr QuestionMan and Tag&Rename can show the target bitrate.

I have tested the 32 kHz / -q-0.55 bitrate behavior with my 25 test file set. The average bitrate was exactly 48 kbps. Here is the Mr QuestionMan report: [a href="http://kotisivu.mtv3.fi/alexb/ha/VorbisB451_32khz_-q-055.htm]VorbisB451_32khz_-q-055.htm[/url]

Just on yesterday I encoded the test file set with pb5 & b4.51 at -1 (standard 44 kHz) and b4.51 at -0.55 (32 kHz). My purpose is to evaluate the possible quality differences a bit. I converted the test tracks to 32 kHz/32-bit wave format before encoding the -0.55 files (I used: foobar, SSRC 32 kHz slow mode, dithered 32-bit). I tried a few 24 kHz files too, but without any ABX testing I got the impression that 32 kHz might be a better source for testing the effect of a lower sample rate.


Aoyumi,

I hope you find these tables useful:

aoTuV prebeta 5 bitrates at -q-1: VencB5_44khz_-q-1.htm
aoTuV beta 4.51 bitrates at -q-1: VorbisB451_44khz_-q-1.htm

The test file set is the same I used for testing various LAME V settings here: http://www.hydrogenaudio.org/forums/index....58&#entry328558
Here is what bitrates the same set produced when I tested various encoders for the Sebastian's multiformat 128 kbps test: bitrates_public2.xls


Edit: typo