There is a new aoTuv pre-beta release out!
This time is focused on q -1
http://www.geocities.jp/aoyoume/aotuv/test.html (http://www.geocities.jp/aoyoume/aotuv/test.html)
Good news!
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
...
What does it mean ?
It probably means more bits are allocated to slightly improve quality at that given nominal bitrate (or quality) compared to the previous tuning.
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.
Just to be sure everyone has seen it :
aoTuV pre-beta5 [20060321] Win32 reference binary
# Quality -1 only.
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.
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?
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 (http://www.hydrogenaudio.org/forums/index.php?showtopic=42866) is distorted in first 1second compared with 4.51. Same issue with sample17 used in 48kbps AAC 2006 test.
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.
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
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]
Just to be sure everyone has seen it :
aoTuV pre-beta5 [20060321] Win32 reference binary
# Quality -1 only.
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] (http://index.php?act=findpost&pid=374451")
No.
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.
[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.
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.
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.
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]
Just to be sure everyone has seen it :
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
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"...
As for semi-lossless, I once started a thread here: http://www.hydrogenaudio.org/forums/index....topic=32651&hl= (http://www.hydrogenaudio.org/forums/index.php?showtopic=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.
(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 (http://www.streamingmedia.com/r/printerfriendly.asp?id=8205)
Sure-Fire Tips for Encoding High-Quality, Low-Bandwidth Audio, Part 2 (http://www.streamingmedia.com/r/printerfriendly.asp?id=8208)
RealNetworks' Signal Processing (http://service.real.com/help/content/audiohints.html#dc_offset)
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 (http://www.weirdtitanradio.com/techinfo/) for example...
SSRC integration would be great too !!!
(note: I know is already done into RareWares (http://www.rarewares.org/ogg.html)' Oggenc builds, but WE wanna use the Lancer builds too )
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%).
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)
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.
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.
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.
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 (http://www.hydrogenaudio.org/forums/index.php?showtopic=15049&view=findpost&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?
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] (http://index.php?act=findpost&pid=375132")
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:
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 (http://kotisivu.mtv3.fi/alexb/ha/VencB5_44khz_-q-1.htm)
aoTuV beta 4.51 bitrates at -q-1: VorbisB451_44khz_-q-1.htm (http://kotisivu.mtv3.fi/alexb/ha/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....58entry328558 (http://www.hydrogenaudio.org/forums/index.php?showtopic=37011&st=50&p=328558&#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 (http://kotisivu.mtv3.fi/alexb/ha/bitrates_public2.xls)
Edit: typo
As for semi-lossless, I once started a thread here: http://www.hydrogenaudio.org/forums/index....topic=32651&hl= (http://www.hydrogenaudio.org/forums/index.php?showtopic=32651&hl=)
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.
[a href="index.php?act=findpost&pid=375057"][{POST_SNAPBACK}][/a]
Actually you could probably not pass an ABX test at 320 with Wavpack Hybrid. Shadowking, Den, and I have tried finding it's transparency threshold. That's the target I use if I plan to transcode later.
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.
Cool... I will add the latest released binary to the wiki if it's not already there. I noticed the encoder pipes out long / short block anaylsis now too? very cool. Your work is well appreciated.
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.
Okay... thanks for that clarification. That could still be useful knowing that I could downmix to mono to reduce the bitrate, if I needed, say, the quality of q-1.
Actually you could probably not pass an ABX test at 320 with Wavpack Hybrid. Shadowking, Den, and I have tried finding it's transparency threshold. That's the target I use if I plan to transcode later.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=375178")
That's not surprising... note that I was talking about using around 400kbit/s. I've read somewhere (I think from WavPack's developer, Bryant, but perhaps without hard proof) that 384 kbit/s should be transparent. I usually add a few kbit/s for a safety margin. But if you really need your files at or under 320 perhaps MPC is the best codec to use for this purpose. I think Guruboolez has done some extensive transcoding listening tests in this context, but it wasn't him that came up with the conclusion about the transcoding from Wavpack. Read [a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=24592]Results of trascoding test to 128k[/url]
(sic)Other threads about this topic:
Lossy transconding, mpc, wavpack or aac (http://www.hydrogenaudio.org/forums/index.php?showtopic=29150&)
DualStream & WavPack, Lossy questions. (http://www.hydrogenaudio.org/forums/index.php?showtopic=28588&)
Wavpack lossy transparency testing, Need help with choosing samples (http://www.hydrogenaudio.org/forums/index.php?showtopic=41678)
The file header shows that information. I found the correct value by testing several different settings.
That make sense. Thank you.
48 kbps TEST 44.1kHz vs 32kHz [aoTuV 4.51]Samples:14 samples - Gabriel's 48kbps AAC test(sample01-14/18)
Encoders and settings:• aoTuV 4.51(Lancer060317P4)| -q -1
• aoTuV 4.51(Lancer060317P4)| -q -0.55 with SSRC resampling(32kHz)
Hardware and software configuration:• Audigy2 soundcard
• Sennheiser HD-580 headphone
• foobar2k 0.83 (en/decode & SSRC)
• java ABC/HR 0.51b
RESULTS
w/o with
resampling resampling
sample01 3.0 2.0
sample02 3.8 3.5
sample03 2.2 1.5
sample04 2.5 2.0
sample05 3.0 2.0
sample06 2.5 2.0
sample07 2.0 2.5
sample08 4.0 4.0
sample09 3.0 2.0
sample10 2.5 2.0
sample11 2.5 2.0
sample12 2.0 2.5
sample13 1.5 2.0
sample14 3.0 1.5
-------------------------------------
MEANS 2.678 2.25
-------------------------------------
test logs (http://www.hydrogenaudio.org/forums/index.php?act=Attach&type=post&id=2121)
COMMENTS:Same bitrate, but slightly worse encoding.
I dis-agree your comment "I got the impression that 32 kHz might be a better source for testing the effect of a lower sample rate."
Well, my difference is: i NEED 32 KHz/mono encodings (for security reason), so i don't care so mutch about quality (even if it must be acceptable).
My focus is on size/bitrate.
Well, my difference is: i NEED 32 KHz/mono encodings (for security reason), so i don't care so mutch about quality (even if it must be acceptable).
My focus is on size/bitrate.
[a href="index.php?act=findpost&pid=375396"][{POST_SNAPBACK}][/a]
I proved that resampling prior to encoding degrade quality/size ratio.
This means 32kHz will be useful only for your
unusual usage (support OggVorbis playback, but only 32kHz?).
Anyway, I follow the preset not unknown settings. That is the best bet.
you didnt prove much of anything.. there are 2 variables.. you need to have 1 variable in order to make a conclusion
the variables in your test:
1. sample rate
2. lowpass frequency
to have a valid test.. you must make the lowpass the same
at -q -.55 the lowpass is 12.78khz @32000hz
lowpass your source at that, then compare (or --advanced-encode-option lowpass_frequency=12.78.. or 14.8 which is the lowpass for -q -1 @44100hz)
(for this test encoder you would have to lowpass the source file since the advanced options aren't present)
then you can determine how samplerate effects encoding quality
you didnt prove much of anything.. there are 2 variables.. you need to have 1 variable in order to make a conclusion
the variables in your test:
1. sample rate
2. lowpass frequency
to have a valid test.. you must make the lowpass the same
at -q -.55 the lowpass is 12.78khz @32000hz
lowpass your source at that, then compare (or --advanced-encode-option lowpass_frequency=12.78.. or 14.8 which is the lowpass for -q -1 @44100hz)
(for this test encoder you would have to lowpass the source file since the advanced options aren't present)
then you can determine how samplerate effects encoding quality
[a href="index.php?act=findpost&pid=375642"][{POST_SNAPBACK}][/a]
I do not think people use such a strange setting in 32kHz encoding. I tested how encoder perform under common use (preset).
In a multi format listening test, 2 variables exist (codec and lowpass).
Do you claim lowpass settings of MP3 and OggVorbis should be same value?
It is unlikely.
48 kbps TEST 44.1kHz vs 32kHz [aoTuV 4.51]
... Same bitrate, but slightly worse encoding.
I dis-agree your comment "I got the impression that 32 kHz might be a better source for testing the effect of a lower sample rate."[a href="index.php?act=findpost&pid=375297"][{POST_SNAPBACK}][/a]
Actually, I meant that 32 kHz might be a better source sample rate than 24 kHz when resampled vs. 44.1 kHz Vorbis files are compared, but as I said I have not properly tested that (yet?).
However, thank you for publishing your results.
You didn't mention what kind of differences you heard. Could you add some comments about that?
Did you compare any of the 32 and 44.1 kHz source wave files with each other for finding out how they differ?
You didn't mention what kind of differences you heard. Could you add some comments about that?
I am sorry. I have no idea how to describe detailed artifacts yet.
There are no explanation for minor artifacts. (though ff123.net is helpful.)
My criterion for rating lossy encodig is the degree of artifacts annoying me.
Did you compare any of the 32 and 44.1 kHz source wave files with each other for finding out how they differ?
Procedure is same as general ABC/HR test.
I guess you did not make 32 kHz wave source files separately.
It would be good to verify the source files also. If the 32 kHz wave files are of high quality they should not differ from 44.1 kHz wave files, except the 16 kHz lowpass that usually has very minor effect. With some samples the difference can be quite inaudible (and for some of us it can be inaudible with all samples).
Also, the used SW & HW playback configuration may or may not have some effect when files of different sample rates are compared.
In your case, Audigy 2 most likely resamples both sample rates internally to 48 kHz, but I guess no one knows if that resampling can cause any audible quality differences with various source sample rates.
I am going to try a personal test that compares:
- 32 kHz aoTuV b451 -q-0.55
- 32 kHz aoTuV b451 -q-0.55 with a higher lowpass (I'll adjust the -q value if needed for getting comparable bitrates)
- 44.1 kHz aoTuv b451 -q-1
- 44.1 kHz aoTuv pb5 -q-1
Perhaps I could add:
- 24 kHz aoTuV b451 with a proper -q value and a 12 kHz lowpass.
I think I'll use some samples from Gabriel's test so the results can be compared. It may take a week or so before I have time to do this test.
[span style='font-size:7pt;line-height:100%']Edit: a small fix[/span]
Actually you could probably not pass an ABX test at 320 with Wavpack Hybrid. Shadowking, Den, and I have tried finding it's transparency threshold. That's the target I use if I plan to transcode later.
[a href="index.php?act=findpost&pid=375178"][{POST_SNAPBACK}][/a]
herding_calls calls (see mp3 problem sample thread) isn't transparent with wavPack -b320hx (see my mp3 'insane' thread).
Considering problem samples things aren't too different as with a perceptual codec. Distortions even sound similar.
Looks like it's always the same thing: what weight should we give to problem samples?
If we do care about them I think it takes something like 400 kbps with wavPack to be totally happy.
I guess you did not make 32 kHz wave source files separately.
It would be good to verify the source files also.
Separate comparison is doomed to be separate result, not fair comparison.
We need to directly compare different sample rate.
The more competitors, harder to test...
I expect to see the performance of pre-beta 5.
Edit: supplement
If "32 kHz -q-0.55 with a higher lowpass" is better than "32 kHz -q-0.55",
lowpass setting is maybe too low for 32kHz preset @given bitrate as gameplaya15143 suggested.
I am going to try a personal test that compares:
- 32 kHz aoTuV b451 -q-0.55
- 32 kHz aoTuV b451 -q-0.55 with a higher lowpass (I'll adjust the -q value if needed for getting comparable bitrates)
- 44.1 kHz aoTuv b451 -q-1
- 44.1 kHz aoTuv pb5 -q-1
Perhaps I could add:
- 24 kHz aoTuV b451 with a proper -q value and a 12 kHz lowpass.
What about comparing
- 44.1 kHz xiph.org 1.1.2 -q-1
- 44.1 kHz aoTuv b4 -q-1
- 44.1 kHz aoTuv b451 -q-1
- 44.1 kHz aoTuv pb5 -q-1
Then, after we found the better codec, perform a test with it at different samplerate/lowpass? Also should this test be open to the public?
Actually you could probably not pass an ABX test at 320 with Wavpack Hybrid. Shadowking, Den, and I have tried finding it's transparency threshold. That's the target I use if I plan to transcode later.
[a href="index.php?act=findpost&pid=375178"][{POST_SNAPBACK}][/a]
herding_calls calls (see mp3 problem sample thread) isn't transparent with wavPack -b320hx (see my mp3 'insane' thread).
Considering problem samples things aren't too different as with a perceptual codec. Distortions even sound similar.
Looks like it's always the same thing: what weight should we give to problem samples?
If we do care about them I think it takes something like 400 kbps with wavPack to be totally happy.
[a href="index.php?act=findpost&pid=375742"][{POST_SNAPBACK}][/a]
I hit 8/8 on 256k hx - volume is raised higher than normal for the test: rise in background hiss. On 320k hx I hit 7/8 though I'm not sure if I hear any difference at all anymore and volume is quite higher than my normal listening level. Can't imagine hearing anything on normal listening situation unless I use dangerous volume levels. What is your abx score? .The artifacts of perceptual codecs are totaly different to me as wavpack *only* adds this hiss, and the rest add all kinds of things.
But thresholds vary with the listener and the sample - and you are correct that 400k can probably fix nearly anything. But back to 'how much weight ?' - I say 'not much' if its not annoying and cannot be heard in normal listening.
In a multi format listening test, 2 variables exist (codec and lowpass).
Do you claim lowpass settings of MP3 and OggVorbis should be same value?
well... a 'scientific' experiment can only have 1 variable... so yea... if the only variable is the codec.. then then one with the least artfacts would win I know many don't agree with this approach, but it is how I do my personal evaluations.
if you want to see the lowpass drop suddenly... encode with
40000hz and 39999hz sample rates
lowpass is 14.8khz and 12.78khz respectively at -q -1
(I know, I know.. who would actually use those sample rates?... but it makes for an interesting example)
I think the lowpass should be calculated depending on sample rate and quality setting.. and not by sample rate ranges like it is
edit: its 14.8khz for q -1 at 40+khz, not 14khz
Where did the number 384 kb/s come from anyways? I know that Bryant (wavPack developer) claimed that to be transparent for hybrid mode, but why such an odd number?
Where did the number 384 kb/s come from anyways? I know that Bryant (wavPack developer) claimed that to be transparent for hybrid mode, but why such an odd number?
[a href="index.php?act=findpost&pid=376940"][{POST_SNAPBACK}][/a]
Bitrates are normally incremented in chunks of 32k, or 64k; hence - 320 + 64 = 384kbps.
I think the lowpass should be calculated depending on sample rate and quality setting.. and not by sample rate ranges like it is
edit: its 14.8khz for q -1 at 40+khz, not 14khz
[a href="index.php?act=findpost&pid=376925"][{POST_SNAPBACK}][/a]
Agreed, but I also think that the user should be able to choose at what freq. to lowpass.
Agreed, but I also think that the user should be able to choose at what freq. to lowpass.
[a href="index.php?act=findpost&pid=377482"][{POST_SNAPBACK}][/a]
you cannot ask for a specific lowpass filter, a specific bitrate and a specific quality at the same time. This is pure logic. Changing any of those changes necesarily the others.
If you simply asked to be able to specify your desired lowpass filter, there's an advanced encoder option... which i don't remember and haven't been able to find it right now :S hope someone can clear this bit.
http://www.die.net/doc/linux/man/man1/oggenc.1.html (http://www.die.net/doc/linux/man/man1/oggenc.1.html)
All the advanced encoder options are exposed in oggdropXPd.
Agreed, but I also think that the user should be able to choose at what freq. to lowpass.
[a href="index.php?act=findpost&pid=377482"][{POST_SNAPBACK}][/a]
we can.. just not on the test encoder 'venc.exe'.. all versions of oggenc can though
--advanced-encode-option lowpass_frequency=XX
XX = the lowpass frequency in khz
aoTuV pre-beta5 [20060408]
http://www.geocities.jp/aoyoume/aotuv/test.html (http://www.geocities.jp/aoyoume/aotuv/test.html)
*** quality -1 (44.1/48kHz) only ***
@ Changed from [20060321].
Small fix and tunings.
What is changed?
@ Changed from [20060321].
Small fix and tunings.
What is changed?
Thats really hard to say, since he hold his source-code hidden from us.
@ Changed from [20060321].
Small fix and tunings.
What is changed?
Thats really hard to say, since he hold his source-code hidden from us.
Indeed, but the source will be available when he has had the chance of finishing his tunings, since the source is GPL'd. If you are interested in helping out with the tunings of ogg vorbis I would suggest you do the following:
I am trying to build up a library of ogg vorbis “problem” samples in order to help the developers to improve the quality of the encoder. I have quite a bit of music myself and I have a small library of samples that sounds bad/distorted at these low-bit rates (~48 kbps), but I need more examples! It would be of great help if you could test the latest pre-beta5 and find short stereo samples (10 - 30 seconds) that shows severe degradation compared to the original and mail them to me.
FLAC format would be preferred but other non-lossy formats are welcomed as well. Please try to keep the examples < 30 seconds. Thank you!
Please send your files to vorbistuning@gmail.com
Best Regards,
Mike
Indeed, but the source will be available when he has had the chance of finishing his tunings, since the source is GPL'd.
Anyone know how to contact him? Cause I want the source code now...
I cant find any mail address on the website
If you are interested in helping out with the tunings of ogg vorbis I would suggest you do the following:
I would like to contribute. But the binary he share dont run on Mac OS X.
Indeed, but the source will be available when he has had the chance of finishing his tunings, since the source is GPL'd.
libvorbis isn't GPL'd. Xiph vorbisenc is, but I'm pretty sure that the test-exe isn't based upon that.
The problem-sample library sounds interesting.
If you are interested in helping out with the tunings of ogg vorbis I would suggest you do the following:
As I said earlier, I am going to post some ABX results, but I have not had enough time to run the tests yet. It will have to wait until the Easter weekend. Naturally, I'll make the samples available or use already existing samples.
Edit: typo
Indeed, but the source will be available when he has had the chance of finishing his tunings, since the source is GPL'd.
libvorbis isn't GPL'd. Xiph vorbisenc is, but I'm pretty sure that the test-exe isn't based upon that.
The problem-sample library sounds interesting.
You are correct, I was misstaken, all vorbis tools are currently GPL'd but the source for ogg libraries are released under a BSD licence. Sorry, my bad.
"Knowledge of Vorbis's specifications is in the public domain. Concerning the specification itself, Xiph.org reserves the right to set the Vorbis specification and certify compliance. Its libraries are released under a BSD-style license and its tools are released under the GPL (GNU General Public License). The libraries were originally released under the GNU Lesser General Public Licence, but a BSD licence was later chosen with the endorsement of Richard Stallman [2]"
http://en.wikipedia.org/wiki/Vorbis (http://en.wikipedia.org/wiki/Vorbis)
Still, even though ogglib is under a BSD license the source code is still available: http://www.xiph.org/downloads/ (http://www.xiph.org/downloads/)
From the source to something else:
Yes the problem sample library is _very_ interesting. I will collect as much samples as I can during the next few months and maybe there would be some way to setup a “problem” sample repository that anyone can benefit from? In the future, maybe not just Ogg Vorbis but also other codes, even though Ogg is my primary concern right now. What do you think?
/Mike
What is changed?
I changed the parameters of tone/noise masking and noise normalization. And the portion which was not able to maintain consistency in threshold control of channel coupling was corrected.
I would like to contribute. But the binary he share dont run on Mac OS X.
I am sorry. Please mail me, if you want to try this version.
libvorbis isn't GPL'd. Xiph vorbisenc is, but I'm pretty sure that the test-exe isn't based upon that.
A venc.exe front end is not a gpl program, either.
I am trying to build up a library of ogg vorbis “problem” samples in order to help the developers to improve the quality of the encoder. I have quite a bit of music myself and I have a small library of samples that sounds bad/distorted at these low-bit rates (~48 kbps), but I need more examples! It would be of great help if you could test the latest pre-beta5 and find short stereo samples (10 - 30 seconds) that shows severe degradation compared to the original and mail them to me.
If there is a sample which became bad from the former encoder, please let me know. However, about the problem sample common to other Vorbis encoders, it is not required (I grasp the many).
@ Changed from [20060321].
Small fix and tunings.
What is changed?
Thats really hard to say, since he hold his source-code hidden from us.
Calm down. Aoyumi always provided the source code once it becomes beta. That is why I can compile it under Linux :-)
BTW, many thanks for that Aoyumi. I hope Monty credits you somewhere, because without your relentless effort Ogg Vorbis would not be competitive at all.
Triza
Calm down. Aoyumi always provided the source code once it becomes beta. That is why I can compile it under Linux :-)
Ok, I understand that Aoyumi release the source code when it becomes beta.
But to reach beta stage he probably need us to test the encoder and report problems. Which is a bit difficult for non-Windows users, when there are only a Windows binary available.
Since its not released with a gpl license I just have too wait and see.
What is changed?
I changed the parameters of tone/noise masking and noise normalization. And the portion which was not able to maintain consistency in threshold control of channel coupling was corrected.
[snip]
Thanks for telling us this.
I do not exhibit a source code at present because I have not finished the minimum test in each mode. for example, quality1-3, 5, and 7-10 are not tested at all.
Moreover, a source code is dirty (Personal comment and code for debugging).
Incidently just the other day I read about the Japanese values/national character. Two things stood out. 1) Modesty 2) hard work and relentless drive to improve things. You are a fine example of these values, Aoyumi. Many thanks again.
Triza
I do not exhibit a source code at present because I have not finished the minimum test in each mode. for example, quality1-3, 5, and 7-10 are not tested at all.
Moreover, a source code is dirty (Personal comment and code for debugging).
Does your changes also improve the quality in the "bitrate management mode" (yes I know the reccomended mode is "quality mode").
aoTuV pre-beta5 [20060408]
http://www.geocities.jp/aoyoume/aotuv/test.html (http://www.geocities.jp/aoyoume/aotuv/test.html)
*** quality -1 (44.1/48kHz) only ***
I don't think so.
Just a personal consideration: why those 'parallel' projects don't have an official page @ Xiph.org or Vorbis.com ?
BTW, many thanks for that Aoyumi. I hope Monty credits you somewhere, because without your relentless effort Ogg Vorbis would not be competitive at all.
Indeed...
Thank you, Aoyumi!
(http://66.49.140.133/assets/icon/clap.gif)
I do not exhibit a source code at present because I have not finished the minimum test in each mode. for example, quality1-3, 5, and 7-10 are not tested at all.
Moreover, a source code is dirty (Personal comment and code for debugging).
Why do you need to test these modes? As I understand changes were made to q -1.0 only? Am I wrong?
I do not exhibit a source code at present because I have not finished the minimum test in each mode. for example, quality1-3, 5, and 7-10 are not tested at all.
Moreover, a source code is dirty (Personal comment and code for debugging).
Why do you need to test these modes? As I understand changes were made to q -1.0 only? Am I wrong?
Doubtless to ensure there are no regressions caused by the changes. Perhaps also to find out whether it improves them at all.
Tuning one thing might make another sound worse, so I assume he has to test whether all the other modes have at least the same (or better) quality.
Tuning one thing might make another sound worse, so I assume he has to test whether all the other modes have at least the same (or better) quality.
I thought tuning of (for
example)
q -1 can affect only (according given example)
q -1.99 -- q -0.99.
Why do you need to test these modes? As I understand changes were made to q -1.0 only? Am I wrong?
Change is not only Quality-1. However, this encoder can be encoded only by Quality-1.
Does your changes also improve the quality in the "bitrate management mode" (yes I know the reccomended mode is "quality mode").
"bitrate management mode" should be the same tendency as "quality mode." However, it is not tested yet.
Who know any news about b5 version?
Who know any news about b5 version?
I repeat a test and tuning mainly now. I want to release it by the end of this month.
May I ask you if tunings will affect the complete level range (-2 to 10) or if the changes will be limited to the lowest VBR settings?
The summer is coming, and I wonder if I'll perform a third row of ~180 kbps listening test. I'm not sure to perform a new one but with new versions of each competitors I'll maybe find extra-motivation
May I ask you if tunings will affect the complete level range (-2 to 10) or if the changes will be limited to the lowest VBR settings?
The summer is coming, and I wonder if I'll perform a third row of ~180 kbps listening test. I'm not sure to perform a new one but with new versions of each competitors I'll maybe find extra-motivation
A next version is different in all bit rates and all sampling rates, but a difference at a low bit rate is big. It is the domain where I make efforts in this time. But pre-echo (not microattack) are different at a high bitrate.
I promised to do some listening tests two months (and two thread pages) ago, but I have been too busy with other activities until now.
By default Vorbis uses 44.1 kHz at -q1. Common sense would say that at a small bitrate like 48 kbps a 32 kHz sample rate would leave more room for vital information. Lame uses 22.05 kHz and iTunes AAC 32 kHz at 48 kbps.
I thought that 32 kHz would have helped Vorbis too, but it seems that it makes things better only with a couple of the samples I tried now.
I tested ten samples from Gabriel's 48 kbps AAC test. I used Vorbis aoTuVb4.51 (oggenc 2.83 2006-04-26 from Rarewares) and b5 (2006-04-08) with the following settings:
Vorbis aoTuV b4.51 32 kHz source "-q -0.55"
Vorbis aoTuV b4.51 32 kHz source "-q -0.55 --advanced-encode-option lowpass_frequency=15"
Vorbis aoTuV b4.51 44.1 kHz source "-q -1"
Vorbis aoTuV b5 44.1 kHz source "-q -1"
I resampled the 32 kHz source files with foobar's SSRC (slow mode) before encoding. I used Koss PortaPro headphones and Terratec DMX 6fire 24/96 sound card.
The results(http://kotisivu.mtv3.fi/alexb/ha/vorbis48table.png)
Despite the few differences I found, it seems that all contenders are tied. It would be interesting to test the new b5 at 32 kHz and 15 kHz lowpass.
ABC/HRABC/HR for Java, Version 0.5b, 09 June 2006
Testname: chanchanT Vorbis
Tester: Alex B
1R = E:\test\Vorbis 48\01\Vorbis32_-055 - 01 - chanchanT.wav
2R = E:\test\Vorbis 48\01\Vorbis32_-055_lp15 - 01 - chanchanT.wav
3R = E:\test\Vorbis 48\01\Vorbis44_-1 - 01 - chanchanT.wav
4L = E:\test\Vorbis 48\01\VorbisB5 - 01 - chanchanT.wav
---------------------------------------
General Comments: Trumpet is very bad, trumpet sound from the best to the worst: 3, 2/4, 1
---------------------------------------
1R File: E:\test\Vorbis 48\01\Vorbis32_-055 - 01 - chanchanT.wav
1R Rating: 2.0
1R Comment:
---------------------------------------
2R File: E:\test\Vorbis 48\01\Vorbis32_-055_lp15 - 01 - chanchanT.wav
2R Rating: 2.1
2R Comment:
---------------------------------------
3R File: E:\test\Vorbis 48\01\Vorbis44_-1 - 01 - chanchanT.wav
3R Rating: 2.2
3R Comment:
---------------------------------------
4L File: E:\test\Vorbis 48\01\VorbisB5 - 01 - chanchanT.wav
4L Rating: 2.1
4L Comment:
---------------------------------------
ABX Results:
________________________________________________________________________
ABC/HR for Java, Version 0.5b, 09 June 2006
Testname: fools Vorbis
Tester: Alex B
1R = E:\test\Vorbis 48\02\Vorbis32_-055_lp15 - 02 - fools.wav
2L = E:\test\Vorbis 48\02\Vorbis32_-055 - 02 - fools.wav
3R = E:\test\Vorbis 48\02\Vorbis44_-1 - 02 - fools.wav
4R = E:\test\Vorbis 48\02\VorbisB5 - 02 - fools.wav
---------------------------------------
General Comments:
---------------------------------------
1R File: E:\test\Vorbis 48\02\Vorbis32_-055_lp15 - 02 - fools.wav
1R Rating: 3.2
1R Comment: Second worst class breaking sound at about 13 s
---------------------------------------
2L File: E:\test\Vorbis 48\02\Vorbis32_-055 - 02 - fools.wav
2L Rating: 3.0
2L Comment: Worst class breaking sound at about 13 s
---------------------------------------
3R File: E:\test\Vorbis 48\02\Vorbis44_-1 - 02 - fools.wav
3R Rating: 3.4
3R Comment: Second best class breaking sound at about 13 s
---------------------------------------
4R File: E:\test\Vorbis 48\02\VorbisB5 - 02 - fools.wav
4R Rating: 3.8
4R Comment: Best class breaking sound at about 13 s
---------------------------------------
ABX Results:
________________________________________________________________________
ABC/HR for Java, Version 0.5b, 09 June 2006
Testname: kraftwerk Vorbis
Tester: Alex B
1L = E:\test\Vorbis 48\03\Vorbis32_-055_lp15 - 03 - kraftwerk.wav
2R = E:\test\Vorbis 48\03\Vorbis32_-055 - 03 - kraftwerk.wav
3R = E:\test\Vorbis 48\03\Vorbis44_-1 - 03 - kraftwerk.wav
4L = E:\test\Vorbis 48\03\VorbisB5 - 03 - kraftwerk.wav
---------------------------------------
General Comments: Distorded, pronounced and strange highs. 3 & 4 have one extra artifact at about 22 s.
---------------------------------------
1L File: E:\test\Vorbis 48\03\Vorbis32_-055_lp15 - 03 - kraftwerk.wav
1L Rating: 1.6
1L Comment:
---------------------------------------
2R File: E:\test\Vorbis 48\03\Vorbis32_-055 - 03 - kraftwerk.wav
2R Rating: 1.6
2R Comment:
---------------------------------------
3R File: E:\test\Vorbis 48\03\Vorbis44_-1 - 03 - kraftwerk.wav
3R Rating: 1.4
3R Comment:
---------------------------------------
4L File: E:\test\Vorbis 48\03\VorbisB5 - 03 - kraftwerk.wav
4L Rating: 1.4
4L Comment:
---------------------------------------
ABX Results:
________________________________________________________________________
ABC/HR for Java, Version 0.5b, 09 June 2006
Testname: Liszt_in_B Vorbis
Tester: Alex B
1R = E:\test\Vorbis 48\04\VorbisB5 - 04 - Liszt_in_B.wav
2L = E:\test\Vorbis 48\04\Vorbis44_-1 - 04 - Liszt_in_B.wav
3L = E:\test\Vorbis 48\04\Vorbis32_-055 - 04 - Liszt_in_B.wav
4R = E:\test\Vorbis 48\04\Vorbis32_-055_lp15 - 04 - Liszt_in_B.wav
---------------------------------------
General Comments: awful, 3 & 4 are slightly better
---------------------------------------
1R File: E:\test\Vorbis 48\04\VorbisB5 - 04 - Liszt_in_B.wav
1R Rating: 1.0
1R Comment:
---------------------------------------
2L File: E:\test\Vorbis 48\04\Vorbis44_-1 - 04 - Liszt_in_B.wav
2L Rating: 1.0
2L Comment:
---------------------------------------
3L File: E:\test\Vorbis 48\04\Vorbis32_-055 - 04 - Liszt_in_B.wav
3L Rating: 1.5
3L Comment:
---------------------------------------
4R File: E:\test\Vorbis 48\04\Vorbis32_-055_lp15 - 04 - Liszt_in_B.wav
4R Rating: 1.5
4R Comment:
---------------------------------------
ABX Results:
________________________________________________________________________
ABC/HR for Java, Version 0.5b, 07 June 2006
Testname: orin_ii Vorbis
Tester: Alex B
1R = E:\test\Vorbis 48\05\Vorbis44_-1 - 05 - orion_ii.wav
2R = E:\test\Vorbis 48\05\Vorbis32_-055_lp15 - 05 - orion_ii.wav
3R = E:\test\Vorbis 48\05\Vorbis32_-055 - 05 - orion_ii.wav
4L = E:\test\Vorbis 48\05\VorbisB5 - 05 - orion_ii.wav
---------------------------------------
General Comments: Bad bad bad
---------------------------------------
1R File: E:\test\Vorbis 48\05\Vorbis44_-1 - 05 - orion_ii.wav
1R Rating: 1.5
1R Comment:
---------------------------------------
2R File: E:\test\Vorbis 48\05\Vorbis32_-055_lp15 - 05 - orion_ii.wav
2R Rating: 1.8
2R Comment:
---------------------------------------
3R File: E:\test\Vorbis 48\05\Vorbis32_-055 - 05 - orion_ii.wav
3R Rating: 1.8
3R Comment:
---------------------------------------
4L File: E:\test\Vorbis 48\05\VorbisB5 - 05 - orion_ii.wav
4L Rating: 1.7
4L Comment:
---------------------------------------
ABX Results:
________________________________________________________________________
ABC/HR for Java, Version 0.5b, 07 June 2006
Testname: sandman Vorbis
Tester: Alex B
1R = E:\test\Vorbis 48\06\Vorbis44_-1 - 06 - sandman.wav
2L = E:\test\Vorbis 48\06\VorbisB5 - 06 - sandman.wav
3R = E:\test\Vorbis 48\06\Vorbis32_-055 - 06 - sandman.wav
4L = E:\test\Vorbis 48\06\Vorbis32_-055_lp15 - 06 - sandman.wav
---------------------------------------
General Comments: Surprisingly good
---------------------------------------
1R File: E:\test\Vorbis 48\06\Vorbis44_-1 - 06 - sandman.wav
1R Rating: 3.8
1R Comment:
---------------------------------------
2L File: E:\test\Vorbis 48\06\VorbisB5 - 06 - sandman.wav
2L Rating: 3.6
2L Comment:
---------------------------------------
3R File: E:\test\Vorbis 48\06\Vorbis32_-055 - 06 - sandman.wav
3R Rating: 3.4
3R Comment:
---------------------------------------
4L File: E:\test\Vorbis 48\06\Vorbis32_-055_lp15 - 06 - sandman.wav
4L Rating: 3.8
4L Comment:
---------------------------------------
ABX Results:
________________________________________________________________________
ABC/HR for Java, Version 0.5b, 07 June 2006
Testname: Stravinsky_Capriccio Vorbis
Tester: Alex B
1L = E:\test\Vorbis 48\07\Vorbis44_-1 - 07 - Stravinsky_Capriccio.wav
2L = E:\test\Vorbis 48\07\Vorbis32_-055 - 07 - Stravinsky_Capriccio.wav
3L = E:\test\Vorbis 48\07\VorbisB5 - 07 - Stravinsky_Capriccio.wav
4L = E:\test\Vorbis 48\07\Vorbis32_-055_lp15 - 07 - Stravinsky_Capriccio.wav
---------------------------------------
General Comments:
---------------------------------------
1L File: E:\test\Vorbis 48\07\Vorbis44_-1 - 07 - Stravinsky_Capriccio.wav
1L Rating: 2.6
1L Comment:
---------------------------------------
2L File: E:\test\Vorbis 48\07\Vorbis32_-055 - 07 - Stravinsky_Capriccio.wav
2L Rating: 2.6
2L Comment:
---------------------------------------
3L File: E:\test\Vorbis 48\07\VorbisB5 - 07 - Stravinsky_Capriccio.wav
3L Rating: 2.6
3L Comment:
---------------------------------------
4L File: E:\test\Vorbis 48\07\Vorbis32_-055_lp15 - 07 - Stravinsky_Capriccio.wav
4L Rating: 2.8
4L Comment:
---------------------------------------
ABX Results:
________________________________________________________________________
ABC/HR for Java, Version 0.5b, 07 June 2006
Testname: Toms Diner Vorbis
Tester: Alex B
1R = E:\test\Vorbis 48\08\VorbisB5 - 08 - TomsDiner.wav
2R = E:\test\Vorbis 48\08\Vorbis32_-055 - 08 - TomsDiner.wav
3R = E:\test\Vorbis 48\08\Vorbis32_-055_lp15 - 08 - TomsDiner.wav
4L = E:\test\Vorbis 48\08\Vorbis44_-1 - 08 - TomsDiner.wav
---------------------------------------
General Comments: Human voice seems to be easy for Vorbis.
---------------------------------------
1R File: E:\test\Vorbis 48\08\VorbisB5 - 08 - TomsDiner.wav
1R Rating: 3.9
1R Comment:
---------------------------------------
2R File: E:\test\Vorbis 48\08\Vorbis32_-055 - 08 - TomsDiner.wav
2R Rating: 3.6
2R Comment:
---------------------------------------
3R File: E:\test\Vorbis 48\08\Vorbis32_-055_lp15 - 08 - TomsDiner.wav
3R Rating: 3.6
3R Comment:
---------------------------------------
4L File: E:\test\Vorbis 48\08\Vorbis44_-1 - 08 - TomsDiner.wav
4L Rating: 4.0
4L Comment:
---------------------------------------
ABX Results:
________________________________________________________________________
ABC/HR for Java, Version 0.5b, 07 June 2006
Testname: Twist & Shout Vorbis
Tester: Alex B
1L = E:\test\Vorbis 48\09\Vorbis32_-055_lp15 - 09 - twist_shout.wav
2R = E:\test\Vorbis 48\09\VorbisB5 - 09 - twist_shout.wav
3R = E:\test\Vorbis 48\09\Vorbis32_-055 - 09 - twist_shout.wav
4L = E:\test\Vorbis 48\09\Vorbis44_-1 - 09 - twist_shout.wav
---------------------------------------
General Comments:
---------------------------------------
1L File: E:\test\Vorbis 48\09\Vorbis32_-055_lp15 - 09 - twist_shout.wav
1L Rating: 3.5
1L Comment:
---------------------------------------
2R File: E:\test\Vorbis 48\09\VorbisB5 - 09 - twist_shout.wav
2R Rating: 3.5
2R Comment:
---------------------------------------
3R File: E:\test\Vorbis 48\09\Vorbis32_-055 - 09 - twist_shout.wav
3R Rating: 3.5
3R Comment:
---------------------------------------
4L File: E:\test\Vorbis 48\09\Vorbis44_-1 - 09 - twist_shout.wav
4L Rating: 3.3
4L Comment:
---------------------------------------
ABX Results:
________________________________________________________________________
ABC/HR for Java, Version 0.5b, 07 June 2006
Testname: waiting Vorbis
Tester: Alex B
1L = E:\test\Vorbis 48\10\Vorbis32_-055_lp15 - 10 - waiting.wav
2L = E:\test\Vorbis 48\10\Vorbis32_-055 - 10 - waiting.wav
3L = E:\test\Vorbis 48\10\Vorbis44_-1 - 10 - waiting.wav
4L = E:\test\Vorbis 48\10\VorbisB5 - 10 - waiting.wav
---------------------------------------
General Comments:
---------------------------------------
1L File: E:\test\Vorbis 48\10\Vorbis32_-055_lp15 - 10 - waiting.wav
1L Rating: 3.8
1L Comment:
---------------------------------------
2L File: E:\test\Vorbis 48\10\Vorbis32_-055 - 10 - waiting.wav
2L Rating: 3.2
2L Comment:
---------------------------------------
3L File: E:\test\Vorbis 48\10\Vorbis44_-1 - 10 - waiting.wav
3L Rating: 3.8
3L Comment:
---------------------------------------
4L File: E:\test\Vorbis 48\10\VorbisB5 - 10 - waiting.wav
4L Rating: 3.5
4L Comment:
---------------------------------------
ABX Results:
The samples are available here: http://www.mp3-tech.org/tests/aac_48/samples/ (http://www.mp3-tech.org/tests/aac_48/samples/)
I analyzed the bitrates with MrQuestionMan. The html reports are available here: Vorbis48kbps_bitrates.rar (http://kotisivu.mtv3.fi/alexb/ha/Vorbis48kbps_bitrates.rar)
Edit: fixed a few typos
The average bitrate was exactly 48 kHz.
I doubt that
Edit: Argh, sorry. You wrote that on March, 25th. I didn't pay attention. Damn weather
Thanks! I fixed the typo now (...better than never).
Edit: damn, a typo again
Thanks, Alex B.
A formal version is the schedule of near inside.
I repeat a test and tuning mainly now. I want to release it by the end of this month.
Jul 1 2006 now
Yeah, it'd be nice to have an official release soon. Regardless, I understand how things can be with other obligations when you're working on a time-consuming project that doesn't pay the bills.
Let the man finish it peacfully. QA and integral part of any development and it takes time. He makes high quality work since regressions are almost unheard of. To stay that way we must not hurry him.
Take your time Aoyumi
Now that I am writing these lines I realized that I do not even know his/her gender. Can anyone help?
Triza
The work list still remains. Therefore, I postponed the release. Sorry.
Now that I am writing these lines I realized that I do not even know his/her gender. Can anyone help?
I am not called her.
I am not called her.
there are only a few females on this forum that I am aware.
There's few reasons for them to be here if their bf's / fiance's are active.
We (the male gender, I mean) have enslaved ourselves to them...
Aoyumi, I just wanted to say a big Thank You for all your work on improving ogg.
You've done a great job so far.
Yeah, I second that- I'm a major Ogg Vorbis fan, and I really owe a lot to you- I can enable my website listeners to hear recordings as I've created them, not as some different-sounding MP3 file.
Question: Will there be much difference at the higher bitrates? It'd be really nice if someone made an effort with OGG at higher bitrates, instead of focusing at q1 (who uses q1?), for example.
Regards,
- Spike
Question: Will there be much difference at the higher bitrates? It'd be really nice if someone made an effort with OGG at higher bitrates, instead of focusing at q1 (who uses q1?), for example.
I think the standard answer is that Vorbis is somewhere between excellent and transparent for most people at higher bitrates, so those rates are not really interesting and fruitful cases to optimize. (FYI I use aotuv-q0 - or even lower - for audio intended for casual downloaders.)
who uses q1
Not me, too high of bitrate for my taste
I think the negative qualitly settings are where the most improvement is needed.. I hope to eventually see -q -3 and take the bitrate even lower.
Aoyumi, you rule! Keep up the great work
(who uses q1?)
Chalk up another one who uses q1 for his Rockboxed Nano and subsequently for his JVC head unit with USB device plus Vorbis support.
Hehe. I used to use -q 0 for my iPaq 2210, now -q 0.5 (52 kbps nominal bitrate)
For my PC, now that is different; ranges from -q 1 to -q 4. Usually I can ABX less than -q 1 on the PC.
These are all usable thanks to you, Aoyumi. Hats off to you!
For lossy I started with Lame and now I use Vorbis -q2.
This decision was made because both my protable (Karma) and PC supports vorbis and as my collection grew I was forced to bring down the bitrate (portable is limited to 20GB).
This is my (ongoing) saga:
LAME --preset standard (with 3.90.3 back in the ol' days)
LAME --preset fast standard
LAME --preset fast medium
Vorbis -q4 (lancer)
Vorbis -q2 (lancer)
q2 gives me 96kbps on average and I have to say I cannot tell the difference to the original. In the future I intend to bring the bitrate lower (64kbps) as the music collection grows. Of coarse I keep a lossless copy of everything so I can switch back and forth whenever needed.
For me, ogg Vorbis q1 sounds great, and that's kind of my standard. Ogg has many great advantages, the main one being that it's completely free, but it is pretty clear to me that AAC is technically superior, and can offer much better quality at extremely low bitrates. I don't think that Ogg can compete against AAC at under 50 kb/s. The problem is that AAC can be something of a pain to get working correctly, I've found, but thanks to Nero, now anyone can encode to it easily, and for free.
Nonetheless, I really appreciate Aoyumi's work. I think that someday perhaps a new version of Ogg Vorbis or something in it's image will even exceed the capabilities of AAC, so it's important to keep developing it. The world needs free codecs like Ogg Vorbis!
q2 gives me 96kbps on average and I have to say I cannot tell the difference to the original. In the future I intend to bring the bitrate lower (64kbps) as the music collection grows. Of course I keep a lossless copy of everything so I can switch back and forth whenever needed
That's what I do for the most part. I have a large number of FLAC files on my machine encode to Vorbis be it whatever the purpose is when I need to
Nonetheless, I really appreciate Aoyumi's work. I think that someday perhaps a new version of Off Vorbis or something in it's image will even exceed the capabilities of AAC, so it's important to keep developing it.
Perhaps if you can get around all of the patents and come up with some innovative ideas. I have seen a few of those already.
I don't expect that I can come up with such ideas... maybe a company I start in the distant future could have some input into such a codec though
I don't expect that I can come up with such ideas... maybe a company I start in the distant future could have some input into such a codec though
Really the only things that need to be done with Vorbis right now are:
- re-writing the encoder to support peeling, a feature that can be exploited due it's VQ backend
- adding 5.1 and ambisonics channel coupling for most modes below -q 6
- annally tuning lower -q modes in relation to masking and noise normalization
other then that the appropriate thing to do for further developement would be to work on some new type of filterbank scheme that's backwards compatible.
I don't know why it doesn't work... (foobar 0.9 b13)
Error writing to file (Generic Error) : file://H:\_zik\wv\1971.The Brothers & Sisters (wv)\1971.Dylan's Gospel.The Brothers & Sisters (ogg)\05. All Along the Watchtower.ogg
For one thing, you could probably stand to update your foobar... 0.9.2 is final now.
-q 0.5 (52 kbps nominal bitrate)
What are you using, a 24khz sample rate? or did you mean -q -0.5?
I wonder how aoTuV b5 is coming along...
Whoopsie. My bad. That should be -q -0.5. I originally written only "-0.5" did three left-arrows, typed "q ", and clicked submit.
Anyways, -q -0.5 actually is 56 kbps, and that's what I use for vocal tracks. For trance/rave/eurodance tracks I go -q -0.7, and that's 52 kbps.
Talk about scraping the bottom of the barrel. With music, -q1 is as low as I'll go (currently ).
Actually, for my PC, -q 1 is the lowest I'll go. It's for my PDA, played in far-from-ideal locations (e.g. inside a bus or train), that -q 0 and lower is acceptable.
Furthermore, since I have extra-sensitivity to HF, I always transcode with foobar2000's EQ acting as an LPF, cutting off (most) of the HF parts. Somehow I found there's less artifacting than transcoding without LPF, making -0.5 (and even -0.7) quite acceptable
Not that you can hear the artifacts in Rave/Trance/Eurodance tracks anyways
Is anybody now about new date of release beta5?
At this point, I try not to go below -q -0.5, but if I go below -q 0 I'll resample as well. (of course I don't like lowpass filters so --advanced-encode-option lowpass_frequency=99 is always used )
-q -.5 --resample 37800
-q -1 --resample 32000
-q -2 --resample 26000 (or lower)
I prefer to resample as apposed to lowpass filtering
wow, I just realized I don't find -q -1.5 to be very interesting at all
At this point, I try not to go below -q -0.5, but if I go below -q 0 I'll resample as well. (of course I don't like lowpass filters so --advanced-encode-option lowpass_frequency=99 is always used )
-q -.5 --resample 37800
-q -1 --resample 32000
-q -2 --resample 26000 (or lower)
I prefer to resample as apposed to lowpass filtering
wow, I just realized I don't find -q -1.5 to be very interesting at all
It doesn't seem wise to force higher lowpass at these bitrates. Almost certainly you are hurting quality. IMO resampling is much more aggressive than lowpassing at these bitrates.
With aoTuV predefined low q values are already tuned by aoyumi in a very competent manner as already proved by listening tests.
Is your lowpass dislike based on listening tests? If it is I'd like to see ABX/ABC-HR tests results proving that resampling is better than lowpassing...
(of course I don't like lowpass filters so --advanced-encode-option lowpass_frequency=99 is always used )
Damn. I'm afraid to find out what that sounds like
Is anybody now about new date of release beta5?
Yet, I cannot decide a release day.
There is various change etc. and many tests are required.
It doesn't seem wise to force higher lowpass at these bitrates. Almost certainly you are hurting quality. IMO resampling is much more aggressive than lowpassing at these bitrates.
I don't seem to be as sensitive to minor artifacts/differences than some people.. that or I just don't care. How is resampling more agressive than lowpassing? I don't quite follow.
With aoTuV predefined low q values are already tuned by aoyumi in a very competent manner as already proved by listening tests.
Almost... some of the illogical things from libvorbis still remain.
use "-q 0 --resample 40000" and "-q 1 --resample 39999" and you will see/hear what I mean (I mentioned this 'issue' before in this very thread). Logic should tell you that 1 sample per second shouldn't make any noticable difference. After that try "-q 0 --resample 39999 --advanced-encode-option lowpass_frequency=15".. the bitrate should be pretty close to the 40000hz encode.
Is your lowpass dislike based on listening tests? If it is I'd like to see ABX/ABC-HR tests results proving that resampling is better than lowpassing...
I never said it was 'better', I said I
prefer it. It's probably due to the assumption that 'lower samplerate' = 'less data to code' which implies that you save some bits. Unfortunately, theory doesn't always work perfectly in practice. For example "-q -2 --resample 26000 --advanced-encode-option lowpass_frequency=99" and "-q -2 --resample 25999 --advanced-encode-option lowpass_frequency=99". These things drive me up a wall. Those rates are the threshold where vorbis switches from the 32khz settings to the 22khz settings (and the example above ^^ is another threshold where things suddenly change). So depending on what you prefer to hear, lowpassing a higher samplerate untill it approximates the bitrate of the lower samplerate might be the way to go, I honestly am unsure/undecided which is better for my ears. And my dislike for lowpass filters came about from 128kbps mp3s back in the days I was still a n00bie. I just got disappointed that there wasn't anything above 16khz (I can hear isolated noise up to ~21khz)... it's been a long journey.
(of course I don't like lowpass filters so --advanced-encode-option lowpass_frequency=99 is always used )
Damn. I'm afraid to find out what that sounds like
-q -2 --advanced-encode-option lowpass_frequency=99 ... if that doesn't get you screaming and covering your ears...
It's better to know, then you don't have to guess/speculate.
Yet, I cannot decide a release day.
There is various change etc. and many tests are required.
The way you put that, it sounds like it might be almost ready. I can't wait.
[edit]spelling[/edit]
I don't seem to be as sensitive to minor artifacts/differences than some people.. that or I just don't care. How is resampling more agressive than lowpassing? I don't quite follow.
resampling adds more noise. I have to say I didn't test it though, I'm just using common sense here.
Almost... some of the illogical things from libvorbis still remain.
use "-q 0 --resample 40000" and "-q 1 --resample 39999" and you will see/hear what I mean (I mentioned this 'issue' before in this very thread). Logic should tell you that 1 sample per second shouldn't make any noticable difference. After that try "-q 0 --resample 39999 --advanced-encode-option lowpass_frequency=15".. the bitrate should be pretty close to the 40000hz encode.
IMO what you should test is -q0 against <<insert your custom -q0 setting here>>, -q1 against <<insert your custom -q1 setting here>> and so forth. What you are doing is using borderline settings that do not say much for real life usage.
AFAIK vorbis adjusts the sampling rate/lowpass automatically to give you the best result. If you think otherwise, prove it.
I never said it was 'better', I said I prefer it.
ok I won't get into a semantics discussion with you. That would lead us nowhere.
I just assumed you
prefer it because it is better. seems not. silly me.
It's probably due to the assumption that 'lower samplerate' = 'less data to code' which implies that you save some bits. Unfortunately, theory doesn't always work perfectly in practice. For example "-q -2 --resample 26000 --advanced-encode-option lowpass_frequency=99" and "-q -2 --resample 25999 --advanced-encode-option lowpass_frequency=99". These things drive me up a wall. Those rates are the threshold where vorbis switches from the 32khz settings to the 22khz settings (and the example above ^^ is another threshold where things suddenly change). So depending on what you prefer to hear, lowpassing a higher samplerate untill it approximates the bitrate of the lower samplerate might be the way to go, I honestly am unsure/undecided which is better for my ears. And my dislike for lowpass filters came about from 128kbps mp3s back in the days I was still a n00bie. I just got disappointed that there wasn't anything above 16khz (I can hear isolated noise up to ~21khz)... it's been a long journey.
I think you are imagining things. ABC/HR and ABX -q[whatever] against the same -q lowpassed/resampled by your custom command line and post back some meaningful results. Otherwise you are violating TOS8 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=3974&view=findpost&p=149481).
Excuse me, but what happens if I don't use --advanced-encode-option lowpass_frequency=99? Does the encoder silently turn lowpass filtering on? Under what conditions?
The encoder always uses lowpass filtering, but
the lowpass frequency will decrease, when you use lower quality settings:
q -2 uses lowpass filtering at 11khz
q -1 uses lowpass filtering at 12khz
q 0 uses lowpass filtering at 13khz
q 1 uses lowpass filtering at 14khz
q 2 uses lowpass filtering at 15khz
q 3 uses lowpass filtering at 16khz
(dont know the exact lowpass frequencies ,I made them up just for explanation)
Useing "--advanced-encode-option lowpass_frequency=99" will override the standart
encoder settings.
Settings the lowpass extremely high like 99Khz, will practical disable it,
because you wont hear ,if 99khz is capped or not.
Your Speakers/headphones wont be able to reproduce these high frequencies anyway
greetings,
Primius
Excuse me, but what happens if I don't use --advanced-encode-option lowpass_frequency=99? Does the encoder silently turn lowpass filtering on? Under what conditions?
At equivalent bitrates (ie 64kbps), the one that is has the lower sample rate will lowpass at a lower frequency (try it with 44100hz and 32000hz).
beto,
oggenc(2) does not automatically resample. If you didn't test out what I described, your loss. I haven't violated tos8, as I have made no comments about quality. I just merely pointed out some things which I find to be very illogical.
Resampling is a preference, much like how I will only encode video at 640x480, 512x384, 400x300, or 320x240 (fullscreen only) and won't use any other resolution. Is it best? not necessarily, it's just how I like to do it. Resampling audio is no exception.
I can't seem to find it right now, but someone had done a small test using -q -1 and -q -.5 --resample 32000 --advanced-encode-option lowpass_frequency=15. They were tied.
Primius,
http://www.hydrogenaudio.org/forums/index....st&p=357461 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=15049&view=findpost&p=357461)
The values you guessed are fairly close to the ones used for 32khz though.
What about -q6? What is the frequency for lowpass filter there?
What about -q6? What is the frequency for lowpass filter there?
If I understand you, this is clearly visible in the table cited in the posting above yours.
What about -q6? What is the frequency for lowpass filter there?
If I understand you, this is clearly visible in the table cited in the posting above yours.
How can I know whether the progression is linear for sure?
So, is it 19khz at -q6, then?
My lowpass frequencies were not real, look Here (http://www.hydrogenaudio.org/forums/index.php?showtopic=15049&st=150&p=357461&#entry357461) for the exact values.
Lowpass also depents on the samplerate (default is 44100hz).
To answer your question, -q6 has no lowpass.
(the table says 48Khz, but thats impossible with 44100hz samplerate, so its turned off there)
I wonder if -q7 with 96khz produces noticeable artifacts, assuming that the encoder processes the hole spectrum.
greetings,
Primius
I wonder if -q7 with 96khz produces noticeable artifacts, assuming that the encoder processes the hole spectrum.
I'd rather expect it to crank the bitrate all the way up to maintain that quality level.
To answer your question, -q6 has no lowpass.
(the table says 48Khz, but thats impossible with 44100hz samplerate, so its turned off there)
I wonder if -q7 with 96khz produces noticeable artifacts, assuming that the encoder processes the hole spectrum.
96/2=48, so -q6 would be enough to encode the entire spectrum of a 96khz sample rate. I don't really remember, but I think the nominal bitrate is higher for 96khz than 48khz at the same quality setting (don't quote me on that, I can't check right now to find out for sure).
The lowpass filter is never shut off, but you can consider it to be effectively off when it is above half the samplerate. It makes me wonder if a few CPU cycles could be saved by disabling it completely.
Yet, I cannot decide a release day.
8th August would sound nice, wouldn't it?
Well, just kidding. Can't wait to get hands on it under Mac OS X though.
8th August would sound nice, wouldn't it?
Possibly it was interesting...
Although there was also change in a code base from pre-beta5, I am concentrating on tuning now.
Yet, I cannot decide a release day.
8th August would sound nice, wouldn't it?
Assuming that '8' is a lucky number for Japanese - it is really good release day. There are two '8's in this date (2006.08.08).
Aoyumi, I read a rather new posting somewhere, people are shying from your tunings because they see it as "beta" so in their mind it's "unstable/test version" or something. The poster recommended you drop the "beta" word.
I just report it to you; if others can show the posting I'd be glad. I can't seem to find it again...
I don't mind the Beta tag, I don't understand why people are afraid of those four letters but they'd be happy to use the same software if it didn't have them.
Aoyumi, I read a rather new posting somewhere, people are shying from your tunings because they see it as "beta" so in their mind it's "unstable/test version" or something. The poster recommended you drop the "beta" word.
I just report it to you; if others can show the posting I'd be glad. I can't seem to find it again...
Before, I considered stopping the beta notation. However, since this kind of software always needs to be tested, I am continuing the beta notation in the symbolic meaning.
*most* "open source" software keeps the 'beta' title forever. Wine has been out for over 10 years, and they *just* adopted the beta title. MPlayer is still 'prerelease', even though they are in their 8th prerelease and are always adding new features. I believe a different methodology needs to be adopted as a whole for all open source software, but that's not aoyumi's responsibility. I'd look at AoTuV as release 4.51, not beta 4.51.. It's confusing to some people, but for something like aoyumi's tunings, being done as a hobby, I'd never feel comfortable giving it a 'version' number mysql (edit: why did I put mysql? I meant MYSELF). Although I do think you should adopt a 'release' number instead. You could call the next release 'release 5' instead of 'beta 5', it wont shy people away, the number stays, and you can wiggle around calling it 'stable'.. Releasing it under 'version' scheme would say 'its stable' to most people, but I think calling it a 'release' would leave room for people to make up their own minds about how stable it is, which is an ideal middle ground for what you're doing.
My 2 cents
I get the impression that most who are not familiar with the open source community shy away from beta as something other people test and they start using when beta becomes release or final. Perhaps a useful middle way are other terms like "release candidate" as that suggests there are no bugs in it in the sense of broken features and it just needs testing. In the strict sense of the word everything that is publically available is "released".
I don't like the -stable title as that suggests it's otherwise unstable, probably shying more people away from it...
I'm not a programmer, let alone one of aoyumi's caliber, but i would assume those who really test aotuv and give meaningful feedback will do so regardless of the presence beta tag.
Another idea would be to include the beta status only as a b in the version number, ie: "aotuv release b4.51"
or you can just manipulate your mind a bit and use those voices in your head to call it: 'stable enough for me, there was no beta included release' or something....
The Linux versioning system is quite good actually.
I considered the version and performed it as follows.
aoTuV page (http://www.geocities.jp/aoyoume/aotuv/)
I considered the version and performed it as follows.
aoTuV page (http://www.geocities.jp/aoyoume/aotuv/)
I see you decided to get rid of the "beta" thing! I'll try it out right away!
w00t! Release version!
*dances with joy*
I considered the version and performed it as follows.
aoTuV page (http://www.geocities.jp/aoyoume/aotuv/)
Correct me if I'm wrong, but the only thing that's changed here is the designation isn't it? ie., the vendor string in info.c. There are no other code changes that I can see, are there?
A new version is due to become a "beta" again. If it is fully tested by people and it is satisfactory, it will become a next release version.
I considered the version and performed it as follows.
aoTuV page (http://www.geocities.jp/aoyoume/aotuv/)
Correct me if I'm wrong, but the only thing that's changed here is the designation isn't it? ie., the vendor string in info.c. There are no other code changes that I can see, are there?
A difference is not in output.
(based on libvorbis 1.1.2 )
I think that more people that might have been "on the fence" with using AoTuV when it was in beta will be much more likely to use this "release" version (even if the internal workings between beta 4.51 and the release are almost negligible).
Good job, and keep up the wonderful work, Aoyumi.
I'll wait for John33's OggDropXPd and oggenc before I update the wiki page
I'll wait for John33's OggDropXPd and oggenc before I update the wiki page
Your wait is over!! New compiles available now.
I considered the version and performed it as follows.
aoTuV page (http://www.geocities.jp/aoyoume/aotuv/)
Some minor suggestions:
1) in the file aoTuV_technical.txt there is the changelog for aoTuV beta4.5, for aoTuV beta4a (this should be the same release of beta4.5) and this last one has the same changelog of the next version, that should be beta4 (apart from "and noise compander parameters"). - I think that the paragraph of beta4a should be removed.
2) in the file aoTuV_technical.txt in the aoTuV beta4.5 paragraph, before 2. and 3. there are two strange characters (should be replaced with spaces);
3) the filename should be libvorbis-aotuv_r1.tar.gz , without the extra tgz .
4) some file (configure , autogen.sh , ...) are missing the executable "x" flag on unix.
5) would be nice to provide a patch against libvorbis-1.1.2 (useful for unix users and distributions, I can provide that if you want).
Anyway, thanks for the release
I considered the version and performed it as follows.
aoTuV page (http://www.geocities.jp/aoyoume/aotuv/)
I don't understand where is the encoder.
I considered the version and performed it as follows.
aoTuV page (http://www.geocities.jp/aoyoume/aotuv/)
I don't understand xhere is the encoder.
Rarewares!!
I considered the version and performed it as follows.
aoTuV page (http://www.geocities.jp/aoyoume/aotuv/)
I don't understand xhere is the encoder.
Rarewares!!
And Lancer (http://homepage3.nifty.com/blacksword/).
but there are not Win32 reference binary ?
r1 has a high compression ratio: all files are 1 byte smaller than beta 4.51 : the string of r1 is on byte smaller:
AO; aoTuV r1 [20051117] (based on Xiph.Org's libVorbis)
AO; aoTuV b4b [20051117] (based on Xiph.Org's libVorbis)
Some minor suggestions:
1) in the file aoTuV_technical.txt there is the changelog for aoTuV beta4.5, for aoTuV beta4a (this should be the same release of beta4.5) and this last one has the same changelog of the next version, that should be beta4 (apart from "and noise compander parameters"). - I think that the paragraph of beta4a should be removed.
2) in the file aoTuV_technical.txt in the aoTuV beta4.5 paragraph, before 2. and 3. there are two strange characters (should be replaced with spaces);
3) the filename should be libvorbis-aotuv_r1.tar.gz , without the extra tgz .
4) some file (configure , autogen.sh , ...) are missing the executable "x" flag on unix.
5) would be nice to provide a patch against libvorbis-1.1.2 (useful for unix users and distributions, I can provide that if you want).
A1. A2.
I checked the above-mentioned problem. I will correct it. Thank you.
A4.
Those files are the same as libvorbis 1.1.2. And I do not understand them...
A5.
I will prepare patch, after correcting the above-mentioned problem.
<<I updated the aoTuV page according to the above. >>
The Lancer/Blacksword notes don't suggest that a 2006 version of aoTuV is built into their August 24, 2006 build.
John33's P4 build in Rarewares ran mighty fast and well on this x64 AMD 3300+.
I converted Pimsleur Japanese learning audio CDs for playback on my Cowon JetAudio. Though I'm trying to learn Japanese without romaji, jumpimg immediately to kana and kanji, I do want to say to Aoyumisan:
Domo arigato gozaimasu!
The Lancer/Blacksword notes don't suggest that a 2006 version of aoTuV is built into their August 24, 2006 build.
Every single .ogg has the vendor tag that reveal the encoder.
tool = BS; Lancer(SSE2) [20060824] (based on aoTuV r1 [20051117])
And you can find detailed change log on this page (http://homepage3.nifty.com/blacksword/readme_j.htm).
^
haregoo:
I don't understand the references to both 20060824 and 20051117.
Is the fact that November 2005 is still cited because the newest codec tweaks only affect encoding at quality ratings under 1.0?
I don't understand the references to both 20060824 and 20051117.
Is the fact that November 2005 is still cited because the newest codec tweaks only affect encoding at quality ratings under 1.0?
aoTuV Release 1 is equal to aoTuV b4.51(20051117) quality-wise, and Lancer 20060824 is based on aoTuV Release 1(r1). In terms of quality, there are NO difference in these encoders.
Did I make myself clear?
aoTuV Release 1 is equal to aoTuV b4.51(20051117) quality-wise, and Lancer 20060824 is based on aoTuV Release 1(r1). In terms of quality, there are NO difference in these encoders.
Did I make myself clear?
Just to make sure to all that there are no difference in code between beta 4.51 and Release 1: this is the difference between libvorbis-1.1.2 patched with beta 4.51 and Release 1:
diff -purN libvorbis-1.1.2/COPYING aotuv-r1_20051117/COPYING
--- libvorbis-1.1.2/COPYING 2006-08-24 14:47:35.000000000 +0200
+++ aotuv-r1_20051117/COPYING 2006-08-23 14:56:14.000000000 +0200
@@ -1,4 +1,4 @@
-aoTuV - Copyright (c) 2003-2005 Aoyumi
+aoTuV - Copyright (c) 2003-2006 Aoyumi
libvorbis - Copyright (c) 2002-2005 Xiph.org Foundation
Redistribution and use in source and binary forms, with or without
diff -purN libvorbis-1.1.2/aoTuV_README-1st.txt aotuv-r1_20051117/aoTuV_README-1st.txt
--- libvorbis-1.1.2/aoTuV_README-1st.txt 2006-08-24 14:47:35.000000000 +0200
+++ aotuv-r1_20051117/aoTuV_README-1st.txt 2006-08-23 15:02:14.000000000 +0200
@@ -1,4 +1,4 @@
-aoTuV beta4.51 release note
+aoTuV Release 1
"aoTuV" tunes up Xiph.Org's libvorbis uniquely.
A license is taken as "BSD-style license" as well as original libvorbis.
@@ -9,16 +9,15 @@ A license is taken as "BSD-style license
Manuke's patch is used for improvement in the speed of sort processing.
When "#define OPT_SORT" of "lib/psy.h" is deleted, the conventional
processing method is used.
+ Thanks! Manuke.
-
-Thanks! Manuke.
-
+ This version is the same contents as aoTuV beta4.51.
aoTuV based on <Xiph.Org libvorbis>
Copyright (c) 2002-2005 Xiph.Org Foundation
-Copyright (c) 2003-2005 Aoyumi
+Copyright (c) 2003-2006 Aoyumi
-AUTHOR : aoyumi <aoyumi at inter7.jp>
\ No newline at end of file
+AUTHOR : aoyumi <aoyumi at gmail.com>
diff -purN libvorbis-1.1.2/lib/info.c aotuv-r1_20051117/lib/info.c
--- libvorbis-1.1.2/lib/info.c 2006-08-24 14:47:35.000000000 +0200
+++ aotuv-r1_20051117/lib/info.c 2006-08-23 12:40:08.000000000 +0200
@@ -416,7 +416,7 @@ static int _vorbis_pack_info(oggpack_buf
}
static int _vorbis_pack_comment(oggpack_buffer *opb,vorbis_comment *vc){
- char temp[]="AO; aoTuV b4b [20051117] (based on Xiph.Org's libVorbis)";
+ char temp[]="AO; aoTuV r1 [20051117] (based on Xiph.Org's libVorbis)";
int bytes = strlen(temp);
/* preamble */
diff -purN libvorbis-1.1.2/lib/psy.c aotuv-r1_20051117/lib/psy.c
--- libvorbis-1.1.2/lib/psy.c 2006-08-24 14:47:35.000000000 +0200
+++ aotuv-r1_20051117/lib/psy.c 2006-08-23 14:25:56.000000000 +0200
@@ -1066,7 +1066,6 @@ void _vp_offset_and_mix(vorbis_look_psy
if(m4_val > 0){
if(fmask && (m4_start<i)){
mdct[i] *= m4_val;
- //logmdct[i]=todB(mdct+i) + .345; // + .345 is a hack
}
}
What about the upcoming release beta5?
We can wait for some surprises?
What about the upcoming release beta5?
We can wait for some surprises?
aoTuV Release 1 is already out. has been for about a month?
Check out http://homepage3.nifty.com/blacksword/ (http://homepage3.nifty.com/blacksword/) for builds.
-Joe
Release 1 is re-branded beta 4.51
Beta 5 is still in pre-beta stage, i.e. not all -q values work (CMIIW)
Release 1 is re-branded beta 4.51
Beta 5 is still in pre-beta stage, i.e. not all -q values work (CMIIW)
Thanks for the clarification.
-Joe
And now beta5 is officially out. Just to clarify so users stumbling upon this thread aren't confused (like I was until I saw today's new thread).
Cheers!
I released the new version of aoTuV.
The difference from pre-beta5 is as follows.
@ The additional code of "channel coupling" added by pre-beta5 was refined. Although it is more efficient, there are somewhat many processing steps.
@ Processing of noise normalization was extended. This was added in order to mitigate collapse of energy.
And tuning.
Hi,
My first post after being a long-time lurker!
Firstly, aoTuV rocks - thankyou Aoyumi.
I have a query/suggestion regarding the version numbering.
Since 'beta 4.51' was rebranded as release 1 (say 1.0) shouldn't that mean that subsequent releases follow the same nomenclature and have version >1.0?
So perhaps beta5 could be known as 1.1beta or 1.1beta1 (like FLAC 1.1.3 beta1)?
Just a suggestion.
Since 'beta 4.51' was rebranded as release 1 (say 1.0) shouldn't that mean that subsequent releases follow the same nomenclature and have version >1.0?
So perhaps beta5 could be known as 1.1beta or 1.1beta1 (like FLAC 1.1.3 beta1)?
Just a suggestion.
I am going to use the version which is stable in the beta version as the release version.
The future release version will be set to "Release2".
I am going to use the version which is stable in the beta version as the release version.
The future release version will be set to "Release2".
Any news on Release2?
For now I keep on using Release1.
Thx for the great job!
Any news on Release2?
The next beta version will become candidate release2.
Any news of when will be available the next beta? What about changes?
Any news on Release2?
For now I keep on using Release1.
Thx for the great job!
Though you might seriously consider using Beta 5 instead. I've been using it since the day the first Lancer version built upon it was made available, without having encountered even a single obvious bug after many thousand encodings so far.
Any news on Release2?
For now I keep on using Release1.
Thx for the great job!
Though you might seriously consider using Beta 5 instead. I've been using it since the day the first Lancer version built upon it was made available, without having encountered even a single obvious bug after many thousand encodings so far.
Isn't Beta 5 the same as Release 1? Jee, how confusing all these version numbering.
Any news of when will be available the next beta? What about changes?
About release day of a new version, it is not yet settled.
Then, about a change from beta5, it will become clear at the time of release. The next version is positioning of a revision of beta5.
Isn't Beta 5 the same as Release 1? Jee, how confusing all these version numbering.
Release1 is equivalent with beta4.51.
IMHO we can't expect significant improvement of vorbis sound quality. I suppose that so-called "vorbis I" near the top of feasible quality.
You can't said that for sure, thats only a your supposition, I'm almost sure that Vorbis I has many room for improvements even in sound quality area....
Maybe we can't expect a significant improvement (something like 128kbps comparable to actual 160kbps) because there is a lot of work to do for only one men... that without breaking the format.