Mr. Aoyumi
I was wondering if your are near to release a new update version of your
"ogg vorbis version".
Also will you focus on better quality at higher bitrates? (which ones?) and what kind of changes will they be on the next update?
Just curious here 'cos im a big fun of your "vorbis tool"
I will appreciate your answer
Thanks in advance
I was wondering if your are near to release a new update version of your
"ogg vorbis version".
I don't have the plan of the release in a new version soon.
Also will you focus on better quality at higher bitrates? (which ones?) and what kind of changes will they be on the next update?
I cannot bring myself to spend much time for a high bit rate. The reason is because the unit/bit price of the storage device continues falling. And lossless codec is the best if I aim at the perfection.
The refinement of the high bit rate at the existing stage is reduction of the pre-echo.
I was wondering if your are near to release a new update version of your
"ogg vorbis version".
I don't have the plan of the release in a new version soon.
The refinement of the high bit rate at the existing stage is reduction of the pre-echo.
Since it's been over a year since your 2006 build, perhaps you can release a beta5.5 in the meantime (like you did with 4.5) with the low-bitrate improvements you made to the post-beta5 builds?
-
Not amusing? If that's true, it's sad to hear...
I think he's gotta a point though... lossless is a reality now and it's just a matter of time for it to be the primary choice of audiophiles.
Disappointing of few hardware support during these years.
Since it's been over a year since your 2006 build, perhaps you can release a beta5.5 in the meantime (like you did with 4.5) with the low-bitrate improvements you made to the post-beta5 builds?
If there are many people requesting it, I may begin a test and preparations to release it.
That would be great Aoyumi. That's three people who'd be interested so far.
I'd like to have a new release too, although i'm more interested in Beta 6 and it's pre-echo improvements. However, i think it's important to have new release to keep interest up for Vorbis and Aoyumi's work.
Kim C has a point.
Please do it Aoyumi. There are a lot of Ogg Vorbis fans outhere who would like to see this project being active. I know you are alone on this and it might be hard for you but im sure that all Vorbis/Aoyumi fans would be glad to see a an update.
I think beta 5.5 is a good thing to keep vorbis and interest "in condition". Some bugs will be fixed, some will be added:-) It is development:-) and it is necessity... But what is bad, the popularity of vorbis is bring down.
I'd like to have a new release too,
Me too Thanks a lot Aoyumi
Please do it Aoyumi. There are a lot of Ogg Vorbis fans outhere who would like to see this project being active. I know you are alone on this and it might be hard for you but im sure that all Vorbis/Aoyumi fans would be glad to see a an update.
+1
(http://66.49.140.133/assets/icon/thumbsup.gif)
Since it's been over a year since your 2006 build, perhaps you can release a beta5.5 in the meantime (like you did with 4.5) with the low-bitrate improvements you made to the post-beta5 builds?
If there are many people requesting it, I may begin a test and preparations to release it.
Yes, please!
I think he's gotta a point though... lossless is a reality now and it's just a matter of time for it to be the primary choice of audiophiles.
Well, I managed to have all my collection in FLAC now for indoor use, but I still use aoTuV Vorbis for my DAP (iAudio X5 & Rockbox ) and it is ABSOLUTELY GREAT for that purpose! I'm satisfied with Q 3,5 for this, but new release would be nice :yes:
THANK YOU VERY MUCH FOR ALL THAT EFFORT, MR. AOYUMI !!!
Vorbis is my codec of choice for music, even for audiobooks, because of the quality per bitrate and especially because of Aoyumi's effort & achievement. Thank you Aoyumi Some of us cannot afford the 32GB iPod Touch & prefer lossy codecs in general.
There will always be interest in new Aoyumi-tuned encoders, you help keep interest in Vorbis alive.
For my hard drive I use APE, but for my portable player I use Ogg Vorbis exclusively, as well as for compressing music videos (mostly AMVs). Improvements are not really necessary (aotuv is already great the way it is), but always welcome!
And of course I support a b5.5 release as well, so yes, +1 for me too!
[edit] Looks like 10 people already posted that they want it. You're pretty popular, Aoyumi!
Same here, +1
many thanks
OK. I begin the work that is necessary for release of beta5.5.
Thank you for many statements.
OK. I begin the work that is necessary for release of beta5.5.
Thank you for many statements.?
Besides new improvements since you've made since the last release, will beta 5.5 include the bug fixes from the official Vorbis 1.2.0 release?
Good to hear that Aoyumi I'm sure you will make OGG Vorbis fans glad. If there is any way that i can help i'll do it.
Looks like 10 people already posted that they want it. You're pretty popular, Aoyumi!
There's one more
Aoyumi is popular I agree
Thanks for your work Aoyumi !
Just adding another voice of support for this. Thanks for all you've done!
count me in!
Give Ogg a boost again!
I like it for my rockbox nano and it's one of the best lossy formats for my Squeezebox. I very much would be interested in a new release. Thank you for the last.
Yeah, i'll just say +1 and thanks for your hard work. Any improvement is of course a welcome improvement, this codec is excellent for quality and filesize.
- Spike
Another "yes" vote, and a big "thank you" to Aoyumi for making the codec so good already.
Another thanks and hoping for another release!
one more.
I use Vorbis on my portable Samsung player. It's the best lossy codec, and Aoyumi made it better. Aoyumi is number one! Thanks for your work!
+1
I use Vorbis for all portable use. Thanks for all the effort put into this great project. I can only hope for Ogg Vorbis to survive.
I also use this version to squeeze music on to my portable player at about 64 kbps. I mostly use this for transcribing/learning songs so the quality doesn't have to be perfect. Very much appreciate your efforts at the low bit rates here!
Another vote here.
Thank you so much for everything you've done
But sure. Here is the next PRO vote !
OK. I begin the work that is necessary for release of beta5.5.
Thank you for many statements.?
Great News!!! Thanks
I just found out that the new cheap SONY flash based mp3 players they all play OGG now... So I'm considering! Not sure as why the aouTuV b5 is the recommended encoder since it introduces noise in the high frequencies...
I just found out that the new cheap SONY flash based mp3 players they all play OGG now... So I'm considering! Not sure as why the aouTuV b5 is the recommended encoder since it introduces noise in the high frequencies...
AFAIK It only introduces noise if you increase the low-pass settings far over the default value.
the noise shows up with "-s %r -Q -q5,000000 - -o %d" which is pretty standard in FB2K, no low-pass setting... You just can't see the noise if you encode with q3 and below because the lowpass will be automatically lower.
can anyone tell me if libvorbis 1.2.0 has aotuv4.5/R1 incorporated into the code?
can anyone tell me if libvorbis 1.2.0 has aotuv4.5/R1 incorporated into the code?
I'm not sure, but if I remember correctly autuv beta 2 was the last to be merged into libvorbis. 1.2.0 brings additional fixes, but no aotuv tunings.
can anyone tell me if libvorbis 1.2.0 has aotuv4.5/R1 incorporated into the code?
http://svn.xiph.org/trunk/vorbis/CHANGES (http://svn.xiph.org/trunk/vorbis/CHANGES):
libvorbis 1.1.0 (2004-09-22) -- "Xiph.Org libVorbis I 20040629"
* merges tuning improvements from Aoyumi's aoTuV with fixups
readme.txt from oggenc_aoTuV_b5.zip:
"Since beta2 was adopted as official 1.1, beta3 uses 1.1 as a base"
That's all.
OK. I begin the work that is necessary for release of beta5.5.
Thank you for many statements.?
Thank You for everything you've done, it's appreciated.
Where do u see noise on Q5 Bourne? im using AoTuV b5 encoder at Q5 and i tested it with the original wav many times and i havent noticed noise at that quality.
Ayoumi have acknowledged the problem so you don't need to be looking for it
(and I'm too lazy to explain now...)
Then i hope he can focus more on this problem at the specific bitrates that causes it on his new beta 5.5 release.
I see Aoyumi has already agreed to release a new version, but for what it's worth, I'm in favor as well. Ogg vorbis is my singular favorite codec, so I'm always in favor of anything that strengthens it!
I released "aoTuV" beta5.5 today.
aoTuV page (http://www.geocities.jp/aoyoume/aotuv/)
Thanks Aoyumi!
I released "aoTuV" beta5.5?today.
aoTuV page (http://www.geocities.jp/aoyoume/aotuv/)
A full set of compiles will be available at Rarewares a little later. You will notice that oggenc2.85 and oggdropXPd1.9.0 in aoTuVb5.5 flavours have grown quite considerably in size. This is due to the inclusion of the new 0.1.3 release of libsamplerate as the built in resampler. According to Erik, the medium and best options are now of notably higher quality.
Aoyumi, thanks a lot
Yatta!
Especially arigatō for pre-echo tunings in this release.
Thank you for this release, Aoyumi
Thank you so much Aoyumi!
Great Man!!!
I released "aoTuV" beta5.5?today.
aoTuV page (http://www.geocities.jp/aoyoume/aotuv/)
Unofficial retranslation of Japanese changelog:
Expanded/extended noise control in impulse blocks. This affects samples with outstanding pre-echo.
Applied pre-echo reduction code to lower bitrates (q -1/-2).
Noise normalization bug fixed. And code was revised.
In addition to the changes/additions above, various parts were retuned.
Compiles now available at Rarewares.
Thnx too, John ... your compile is much faster on my Computer
Thank you very much, Aoyumi and John.
Vorbis is my favourite audio codec.
Best regards
akapuma
Thank YYYYYOOOOOUUUUUUUU
Thanks Aoyumi! Vorbis rulez!
I released "aoTuV" beta5.5?today.
aoTuV page (http://www.geocities.jp/aoyoume/aotuv/)
Great work Aoyumi! Thanks a lot. :c)
/Kef
Though I'm not a vorbis user I admire your great work, Aoyumi.
Just tried your new version at -q4 with regular music and some problem samples. Wonderful quality!
Thx Aoyumi!!! Pre-echo is real less.
Why this wonderful news is not on the main HA page???
That is great news indeed. Just can't wait to get LANCER version of "aoTuV" beta5.5
Thx Aoyumi!!! Pre-echo is real less.
Why this wonderful news is not on the main HA page???
I couldn't agree more ...
/Kef
Thank you very much for the new release. Been using Vorbis for all my portable use for quite a while now thanks to your tunings.
I released "aoTuV" beta5.5?today.
aoTuV page (http://www.geocities.jp/aoyoume/aotuv/)
Thank you very much for the release, Aoyumi!
Charles
Thank You Aoyumi and John
I too await LANCER version of "aoTuV" beta5.5
+1- I hope BlackSword is still going to do Lancer builds
Is he on these forums?
Anyway, thanks very much for your hard work Aoyumi. It puts all the hot air over MP3 beta 5 and 6 and final 3.98 never coming out to shame when one guy can simply finetune an encoder himself and get on with it.
- Spike
Aoyumi you did it finally
Thanks for all.
I see a lot of happy faces, hehe you made ".ogg vorbis" fans happy again.
Thanks again
Many many thanks!
Thanks for your hard work, Aoyumi, and thanks for hosting so many goodies for us, john33!
Also thanks alot from me, I think without your work I wouldn't use Vorbis as of today, it's nice to see someone actively improving one of my favorite codecs
Sugoi!
Otsukaresama deshita!
The first thing I encoded was a conversation exercise CD that came with a Japanese language text.
The Oggdrop XPd functions of converting to mono and down-sampling are a huge help for making great-sounding tiny files. ( I wish those functions, especially the new resampler, were in FLACdrop.)
Aoyumi-san was in large part responsible for my resolve to learn Japanese.
Gambarimasho!
This makes a fine birthday present. I'm glad you put this together. As an individual and on behalf of the community, I thank you.
+ The differences from the aoTuV beta 5...
+
+ 1. The frequency domain width of M6 was revised.
+
+ 2. For q-1/-2, a pre-echo reduction code was applied (M3). In addition,
+ the M3 code was improved.
+
+ 3. The floor setup parameters in the low bit-rate was changed.
+
+ 4. The part including bug of noise normalization was rewritten.
+
+ 5. libvorbis 1.2.0 were merged. Furthermore, a revision of Bug #300 and
+ #1229 was applied.
+
+ 6. The ATH curve of the high frequency area (more than 32kHz) was revised.
+
+ ...and I tune up many parameters.
+
+
+ 2008/03/30
+ Aoyumi
ckjnigel: The impetus to learn Japanese came from Aoyumi-san, eh? That's awesome... XD
You know what else is awesome...? For the first time, I'm unable to consistently abx some of my music at -q0 (lowpass 18).
Are there any noticeable improvements when using q -5 between the previous beta and the current one?
Also, are there noticeable differences between using Auyumi's tuned-up build and Xiph.org's latest build at q -5?
Thanks for your hard work, Auyumi!
Im kind of interested about the first question aswell.
Is there anyone who did any advance tests on the new built?
Thanks
Audible improvements at q5? If a5 was transparent to you before, there's no "audible improvement" possible, no matter what build you use.
But what about the pre-echo problems at high bitrates that some people mention on the previous beta? Is there any pre-echo reduction at q5 on the new beta?
Does anybody else have problems with this beta 5.5 release? I encoded a few albums at -q0 for my portable player (iRiver S10) and even though the files plays in foobar, I only get 2-4 seconds of each song on my portable and then it tries to play the next song which is also about 4 seconds long and so on and so on... It even says the songs are 4 seconds long!
Aoyumi, did you change something in the bit-stream?
/Kef
Does anybody else have problems with this beta 5.5 release? I encoded a few albums at -q0 for my portable player (iRiver S10) and even though the files plays in foobar, I only get 2-4 seconds of each song on my portable and then it tries to play the next song which is also about 4 seconds long and so on and so on... It even says the songs are 4 seconds long!
Aoyumi, did you change something in the bit-stream?
/Kef
AFAIK, aoTuV beta5.5 uses official Vorbis 1.2.0 as its base. Previous versions use Vorbis 1.1.x.
Try Vorbis 1.2.0 (Xiph.Org libVorbis I 20070622) and you'll see if this matters.
Anyway, my Samsung YP-U3 plays such files (aoTuV beta 5.5, q0) without problems.
Does anybody else have problems with this beta 5.5 release? I encoded a few albums at -q0 for my portable player (iRiver S10) and even though the files plays in foobar, I only get 2-4 seconds of each song on my portable and then it tries to play the next song which is also about 4 seconds long and so on and so on... It even says the songs are 4 seconds long!
Aoyumi, did you change something in the bit-stream?
/Kef
AFAIK, aoTuV beta5.5 uses official Vorbis 1.2.0 as its base. Previous versions use Vorbis 1.1.x.
Try Vorbis 1.2.0 (Xiph.Org libVorbis I 20070622) and you'll see if this matters.
Anyway, my Samsung YP-U3 plays such files (aoTuV beta 5.5, q0) without problems.
Ah, good catch, that might be it... I'll check
Does anybody else have problems with this beta 5.5 release? I encoded a few albums at -q0 for my portable player (iRiver S10) and even though the files plays in foobar, I only get 2-4 seconds of each song on my portable and then it tries to play the next song which is also about 4 seconds long and so on and so on... It even says the songs are 4 seconds long!
Aoyumi, did you change something in the bit-stream?
/Kef
AFAIK, aoTuV beta5.5 uses official Vorbis 1.2.0 as its base. Previous versions use Vorbis 1.1.x.
Try Vorbis 1.2.0 (Xiph.Org libVorbis I 20070622) and you'll see if this matters.
Anyway, my Samsung YP-U3 plays such files (aoTuV beta 5.5, q0) without problems.
Ah, good catch, that might be it... I'll check
You where right, it's not aoTuV beta5.5, it is Vorbis 1.2.0 that causes the problem.
Good catch. Thanks! (off to iRiver to ask for a firmware-update)
/Kef
But that's not the whole story though... oggdrop works just fine with both beta5.5 and Vorbis 1.2.0, but not with foobar and either command line encoder... Strange!
But that's not the whole story though... oggdrop works just fine with both beta5.5 and Vorbis 1.2.0, but not with foobar and either command line encoder... Strange!
Which command line encoders are you referring to? oggenc2 output
should match oggdropXPd output and if there is some fatal difference, I need to look into it.
But that's not the whole story though... oggdrop works just fine with both beta5.5 and Vorbis 1.2.0, but not with foobar and either command line encoder... Strange!
Which command line encoders are you referring to? oggenc2 output should match oggdropXPd output and if there is some fatal difference, I need to look into it.
I'm referring to oggenc2.
But that's not the whole story though... oggdrop works just fine with both beta5.5 and Vorbis 1.2.0, but not with foobar and either command line encoder... Strange!
Which command line encoders are you referring to? oggenc2 output should match oggdropXPd output and if there is some fatal difference, I need to look into it.
I'm referring to oggenc2.
I can send you the files, if you like, but ... I would probably be the next target of RIAA...
What command line are you using from foobar and what options are you specifying in oggdropXPd? Sorry to be a pain, but I need to know whether foobar is doing something different.
What command line are you using from foobar and what options are you specifying in oggdropXPd? Sorry to be a pain, but I need to know whether foobar is doing something different.
I'm just using default settings and -q0.
oggenc2 and oggdropXPd downloaded from rarewares
What command line are you using from foobar and what options are you specifying in oggdropXPd? Sorry to be a pain, but I need to know whether foobar is doing something different.
I'm just using default settings and -q0.
oggenc2 and oggdropXPd downloaded from rarewares
No tagging at all?
What command line are you using from foobar and what options are you specifying in oggdropXPd? Sorry to be a pain, but I need to know whether foobar is doing something different.
I'm just using default settings and -q0.
oggenc2 and oggdropXPd downloaded from rarewares
No tagging at all?
Ehum... I usually don't use tags but I checked the source (reference libFLAC 1.1.2 20050205) files and yes they are tagged.
What command line are you using from foobar and what options are you specifying in oggdropXPd? Sorry to be a pain, but I need to know whether foobar is doing something different.
I'm just using default settings and -q0.
oggenc2 and oggdropXPd downloaded from rarewares
No tagging at all?
Ehum... I usually don't use tags but I checked the source (reference libFLAC 1.1.2 20050205) files and yes they are tagged.
Maybe it would be a good idea to use wav's to eliminate any tagging problem?
<edit>
I tested with a wav file and it worked perfectly, when I use the flac file it doesn't (using foobar2000 for both). Seems like some tagging problem to me.
</edit>
<edit2>
I removed the tags from the ogg file and still no luck
</edit2>
......
Maybe it would be a good idea to use wav's to eliminate any tagging problem?
<edit>
I tested with a wav file and it worked perfectly, when I use the flac file it doesn't (using foobar2000 for both). Seems like some tagging problem to me.
</edit>
<edit2>
I removed the tags from the ogg file and still no luck
</edit2>
So, if I understand this correctly, the ogg files created from the FLAC files using foobar, with tags copied from the FLAC files, fail in your portable.
The ogg files created from the FLAC files using oggdropXPd are read fine in the portable, but do they contain tags, or not?
The fact that removing the tags from the ogg files doesn't solve the problem may suggest that the tagging routines in foobar are behaving in a way that is not quite standard, or if the oggdropXPd generated files aren't created with tags, then there is something about tagging that the iRiver doesn't like.
Edit: Sorry, thinking about it, the comment about foobar tagging routines is probably complete nonsense since it will presumably just feed the tagging routines in oggenc2!
So, if I understand this correctly, the ogg files created from the FLAC files using foobar, with tags copied from the FLAC files, fail in your portable.
Correct
The ogg files created from the FLAC files using oggdropXPd are read fine in the portable, but do they contain tags, or not?
They don't contain any tags.
The fact that removing the tags from the ogg files doesn't solve the problem may suggest that the tagging routines in foobar are behaving in a way that is not quite standard, or if the oggdropXPd generated files aren't created with tags, then there is something about tagging that the iRiver doesn't like.
Yeah, that's the question isn't it?
Anyway, I'm glad to find out it probably isn't a bit-stream problem. This is the first time I have encountered this problem and I have done a lot of conversions with both foobar and oggdropXPd. But as a previous poster suggested, it might have something to do with the new 1.2.0 libvorbis. I haven't used 1.2.0 until now (there was no reason to) and since aoTuVb5.5 is using 1.2.0 that might indeed be the problem. Luckily, there are workarounds for me.
<edit>
I'll test with libvorbis 1.2.0 later today and let you know if the problem is still there.
</edit>
Edit: Sorry, thinking about it, the comment about foobar tagging routines is probably complete nonsense since it will presumably just feed the tagging routines in oggenc2!
foobar2000 calls oggenc.exe with commandline like that:
"C:\Program Files\foobar2000_09\oggenc.exe" -s 38500796 -Q -q5,500000 - -o "temp-76C393E9766F3169AEED5705EBD7EA3B.ogg"
So fb2k don't rely on codecs when tagging.
Try a conversion using oggdropXPd and set the option to copy the FLAC tags. If that causes a problem, then the tags would seem to be the problem.
Slightly more confusing is that the tagging routines in the library appear unchanged relative to the previous version.
Try a conversion using oggdropXPd and set the option to copy the FLAC tags. If that causes a problem, then the tags would seem to be the problem.
Slightly more confusing is that the tagging routines in the library appear unchanged relative to the previous version.
I did convert using oggdropXpd and copying the tags. It worked perfectly.
Try a conversion using oggdropXPd and set the option to copy the FLAC tags. If that causes a problem, then the tags would seem to be the problem.
Slightly more confusing is that the tagging routines in the library appear unchanged relative to the previous version.
I did convert using oggdropXpd and copying the tags. It worked perfectly.
In which case, the problem must lie on the foobar tagging! Which, in the context of lvqcl's post, certainly seems a possibility. Mal-formed tags, I would guess, although somewhat unexpected.
Does anybody else have problems with this beta 5.5 release? I encoded a few albums at -q0 for my portable player (iRiver S10) and even though the files plays in foobar, I only get 2-4 seconds of each song on my portable and then it tries to play the next song which is also about 4 seconds long and so on and so on... It even says the songs are 4 seconds long!
Aoyumi, did you change something in the bit-stream?
/Kef
I don't discover the cause of the problem. However, I know that a problem gets up by the state of the comment header at a low bit rate depending on DAP.
I think that it is not a problem of the library. Because the reason is because the problem does not depend on the version of the library.
I suppose that padding domain of the Vorbis comment or the size of the Vorbis comment domain influences it.
Are you still interested in material that provokes artefacts, to tune your psycho acoustics further? Or may I possibly add some "Advanced Encoder Options" here to test for you if they improve the result?
__
Listening to Ogg Vorbis audio with a Home Cinema set was in general satisfying for me. Most of my CDs sound well even when compressed with just Quality 3/10.
Some time ago I bought a pocket audio player which supports Ogg Vorbis files (Samsung YP-...), and I am in general satisfied too. Until I heard a remarkable exception. So I compared several oggenc2 versions (usually I prefer the aoTuV variants, the song I heard was encoded with aoTuV-b4), and even with the current b5.5 "release", I still get "twitting" noise at quality 3 with:
The Prodigy: 04. Your Love [Remix] (Experience, 1992)
for the synth percussion at the time 01:12-01:14, and even more at the time 03:29-03:31. I understand that this sound is possibly very provoking, it has sharp attacks and some flat "pappy" noise afterwards.
I can send you some material if required (e.g. short cuts around these positions).
Are you still interested in material that provokes artefacts, to tune your psycho acoustics further? Or may I possibly add some "Advanced Encoder Options" here to test for you if they improve the result?
__
Listening to Ogg Vorbis audio with a Home Cinema set was in general satisfying for me. Most of my CDs sound well even when compressed with just Quality 3/10.
Some time ago I bought a pocket audio player which supports Ogg Vorbis files (Samsung YP-...), and I am in general satisfied too. Until I heard a remarkable exception. So I compared several oggenc2 versions (usually I prefer the aoTuV variants, the song I heard was encoded with aoTuV-b4), and even with the current b5.5 "release", I still get "twitting" noise at quality 3 with:
The Prodigy: 04. Your Love [Remix] (Experience, 1992)
for the synth percussion at the time 01:12-01:14, and even more at the time 03:29-03:31. I understand that this sound is possibly very provoking, it has sharp attacks and some flat "pappy" noise afterwards.
I can send you some material if required (e.g. short cuts around these positions).
I understand the cause of the problem. But, I don't find an efficient solution for the moment.
Probably the basic solution is not possible in "Advanced Encoder Options".
...
When somebody finds the good method, I am glad.
Thanks for this new release, Aoyumi! The low bitrates keep getting better and better.
Also, I just asked in the Vorbis 1.2.0 release thread whether they included any of your tunings (beyond what was put in the Vorbis 1.1.0 release). But looking here, I see I don't need to worry, since you already integrated Vorbis 1.2.0 into your latest release.
I second making a news thread.
Hi,
thank you and keep up the good work^^
HF, Clobon
I understand the cause of the problem. But, I don't find an efficient solution for the moment.
Probably the basic solution is not possible in "Advanced Encoder Options".
...
When somebody finds the good method, I am glad.
In that case there is only one solution... "More bitrate". Alright then - Prodigy deserves it!
@john33 & lvgcl:
Guys, should we let know foobar2000 developers about that bug or you just have done it already?
And as somebody Spikey already asked - does anyone knows if BlackSword is working on optimized version of Aoyumi 5.5. Do we have his e-mail or anybody can let him now about new version?
The problem detected by LigH is audible up to q6.
100% Killer sample!
The problem detected by LigH is audible up to q6.
100% Killer sample!
In that case: Rooobeeertooo!!! (Amorim)
He may love that for a possibly fresh ABX test with current encoders, if he does them still.
I tested beta 5.5 on some similar electronic samples. I couldn't reproduce described above problem. It seems as this isn't a production problem.
I am happy
Thanks! Most excellent. I think doing another multiformat 64 kbps is overkill but what about 80 kbps? I know there was something in the works from Sebastien but hadn't heard about it in a while (also out of the loop recently).
Aoyumi, if you figure out how to fix such a problem, would you release a post-beta5.5 with the fix (or a b5.51 fix as in b4.51)? Thanks for your efforts.
Aoyumi, if you figure out how to fix such a problem, would you release a post-beta5.5 with the fix (or a b5.51 fix as in b4.51)? Thanks for your efforts.
I will announce it in one way or another if I found a better method.
However, anyone other than me can challenge problem improvement.
aoTuV beta5.5 with libVorbis 1.2.1 RC1 released
uri: http://www.geocities.jp/aoyoume/aotuv/test.html (http://www.geocities.jp/aoyoume/aotuv/test.html)
aoTuV beta5.5 with libVorbis 1.2.1 RC1 released
uri: http://www.geocities.jp/aoyoume/aotuv/test.html (http://www.geocities.jp/aoyoume/aotuv/test.html)
Can anyone help out with the correct Foobar converter parameters for the windows binary? I've tried a number of different combinations with no success (my existing oggenc parameters don't work).
Correction, worked it out (can't get pipes to work though):
-q7 %s %d
Can anyone help out with the correct Foobar converter parameters for the windows binary? I've tried a number of different combinations with no success (my existing oggenc parameters don't work).
Correction, worked it out (can't get pipes to work though):
-q7 %s %d
Please try the following custom parameters.
-q7 - %d
Look at a manual bundled with the reference binary of "aoTuV beta 5.5" about "venc.exe".
Can anyone help out with the correct Foobar converter parameters for the windows binary? I've tried a number of different combinations with no success (my existing oggenc parameters don't work).
Correction, worked it out (can't get pipes to work though):
-q7 %s %d
Please try the following custom parameters.
-q7 - %d
Look at a manual bundled with the reference binary of "aoTuV beta 5.5" about "venc.exe".
Yes I did try that first and it didn't work. I'm using Foobar2000 v0.9.5.4 beta 3:
Source: "C:\Documents and Settings\user\Desktop\shirk_itchytime_sample.mp3"
An error occured while writing to file (The encoder has terminated prematurely with code 1; please re-check parameters) : "C:\Documents and Settings\user\Desktop\00 - shirk_itchytime_sample.ogg"
Additional information:
Encoder stream format: 44100Hz / 2ch / 32bps
Command line: "C:\Program Files\foobar2000 new\venc.exe" -q7 - "00 - shirk_itchytime_sample.ogg"
Working folder: C:\Documents and Settings\user\Desktop\
Conversion failed: The encoder has terminated prematurely with code 1; please re-check parameters
1 out of 1 tracks converted with major problems.
Yes I did try that first and it didn't work. I'm using Foobar2000 v0.9.5.4 beta 3:
Source: "C:\Documents and Settings\user\Desktop\shirk_itchytime_sample.mp3"
An error occured while writing to file (The encoder has terminated prematurely with code 1; please re-check parameters) : "C:\Documents and Settings\user\Desktop\00 - shirk_itchytime_sample.ogg"
Additional information:
Encoder stream format: 44100Hz / 2ch / 32bps
Command line: "C:\Program Files\foobar2000 new\venc.exe" -q7 - "00 - shirk_itchytime_sample.ogg"
Working folder: C:\Documents and Settings\user\Desktop\
Conversion failed: The encoder has terminated prematurely with code 1; please re-check parameters
1 out of 1 tracks converted with major problems.
There must be the bit depth in 16bit. Your setting becomes 32bit.
Yes, I tried that:
Source: "C:\Documents and Settings\user\Desktop\14 - Piva di Bedonia e di Scurano.m4a"
An error occured while writing to file (The encoder has terminated prematurely with code 0; please re-check parameters) : "C:\Documents and Settings\user\Desktop\14 - Piva di Bedonia e di Scurano.ogg"
Additional information:
Encoder stream format: 44100Hz / 2ch / 16bps
Command line: "C:\Program Files\foobar2000 new\venc.exe" -q5 - "14 - Piva di Bedonia e di Scurano.ogg"
Working folder: C:\Documents and Settings\user\Desktop\
Conversion failed: The encoder has terminated prematurely with code 0; please re-check parameters
1 out of 1 tracks converted with major problems.
Anyway Aoyumi, it is not a big problem, the new encoder works very well, and John33 or someone else can compile your source code. Thank you for all your excellent work!
Yes, I tried that:
Source: "C:\Documents and Settings\user\Desktop\14 - Piva di Bedonia e di Scurano.m4a"
An error occured while writing to file (The encoder has terminated prematurely with code 0; please re-check parameters) : "C:\Documents and Settings\user\Desktop\14 - Piva di Bedonia e di Scurano.ogg"
Additional information:
Encoder stream format: 44100Hz / 2ch / 16bps
Command line: "C:\Program Files\foobar2000 new\venc.exe" -q5 - "14 - Piva di Bedonia e di Scurano.ogg"
Working folder: C:\Documents and Settings\user\Desktop\
Conversion failed: The encoder has terminated prematurely with code 0; please re-check parameters
1 out of 1 tracks converted with major problems.
Anyway Aoyumi, it is not a big problem, the new encoder works very well, and John33 or someone else can compile your source code. Thank you for all your excellent work!
I discovered a small mistake in a pipe input processing part. And it is fixed now.
Please try a new version.
Aoyumi... I have tested it and it works perfectly now... thank you!
Hey, thanks for continuing to work on Vorbis.
Does anyone know if there is any chance of the "Lancer" guys compiling a new version using the latest AOTUV release?
- Jason
And don't forget RareWares... When it is there, it is released.
Does anyone know if there is any chance of the "Lancer" guys compiling a new version using the latest AOTUV release?
I emailed them in English a month or so ago, but no reply... they probably didn't know who I was or what I was saying!
Does anyone know if there is any chance of the "Lancer" guys compiling a new version using the latest AOTUV release?
I emailed them in English a month or so ago, but no reply... they probably didn't know who I was or what I was saying!
Ha!! Well maybe someone on this forum who speaks Japanese can give it a shot. In my humble opinion (and this probably goes against one of the forum rules) the combination of AOTUV quality and Lancer speed is the best lossy compression codec on the planet.
- Jason
Considering the amount of work involved in the Lancer builds, I imagine Blacksword is waiting for libvorbis 1.2.1 to be fully released before doing anything, as am I.
Considering the amount of work involved in the Lancer builds, I imagine Blacksword is waiting for libvorbis 1.2.1 to be fully released before doing anything, as am I.
"Considering the amount of work involved in the Lancer builds, I imagine Blacksword is waiting for libvorbis 1.2.1 to be fully released before doing anything, as am I."
Well if that is the case I guess I'll just have to wait. You are another one here who does great work -- thank you.
- Jason
Is there a version of the aoTuV beta5.5 encoder that works with Windows 98SE?
Is there a version of the aoTuV beta5.5 encoder that works with Windows 98SE?
Probably they will work in windows98SE.
"Considering the amount of work involved in the Lancer builds, I imagine Blacksword is waiting for libvorbis 1.2.1 to be fully released before doing anything, as am I."
Well if that is the case I guess I'll just have to wait. You are another one here who does great work -- thank you.
I must say Lancer is the reason why I prefer Vorbis over Nero AAC for my "living room listening notebook" - 35x vs. 13x encoding speed is a good argument.
Is there a version of the aoTuV beta5.5 encoder that works with Windows 98SE?
Probably they will work in windows98SE.
And they do. Both "original" (http://www.geocities.jp/aoyoume/aotuv/binary/oggenc_aoTuV_b5.5.zip) and "ICL 9.1" oggenc from RareWares.
aoTuV beta5.5 include PreAmp released
uri: http://www.geocities.jp/aoyoume/aotuv/test.html (http://www.geocities.jp/aoyoume/aotuv/test.html)
There is one small bug in the binary:
If the track title contains a ".", e.g. song called "99.9", when using foobar to write filenames using %tracknumber% - %title%, the ogg is written, but the filename is truncated, and the file has no tags.
This occurs on B5.5 and on the latest 20080722 version, but does not occur with the John33 compiles or with Lancer.
I can get around it by using this formatting string in Foobar 2000 converter:
%album artist%\%album%\$num(%tracknumber%,2) - $replace(%title%,.,_)
There is one small bug in the binary:
If the track title contains a ".", e.g. song called "99.9", when using foobar to write filenames using %tracknumber% - %title%, the ogg is written, but the filename is truncated, and the file has no tags.
This occurs on B5.5 and on the latest 20080722 version, but does not occur with the John33 compiles or with Lancer.
I can get around it by using this formatting string in Foobar 2000 converter:
%album artist%\%album%\$num(%tracknumber%,2) - $replace(%title%,.,_)
Thank you for reports. I updated the binary of the test page.
Thank you Aoyumi, it is fixed!
The quality of aoTuV after beta 5 at low bitrates seems quite good (I am referring here specifically to -q0). I think I may fail to abx some of my audio even at q0, if the lowpass was raised to 16khz.
Is there a way to specify lowpass with venc.exe (or can such a feature be implemented)? The quality is becoming too good for me to notice artifacts, so the lowpass is the only thing holding me back from abx. Thank you, Aoyumi.
The quality of aoTuV after beta 5 at low bitrates seems quite good (I am referring here specifically to -q0). I think I may fail to abx some of my audio even at q0, if the lowpass was raised to 16khz.
Is there a way to specify lowpass with venc.exe (or can such a feature be implemented)? The quality is becoming too good for me to notice artifacts, so the lowpass is the only thing holding me back from abx. Thank you, Aoyumi.
Present venc.exe does not have the device to set lowpass.
However, I am going to release it as a new version after release of libvorbis1.2.1 formally.
The quality of aoTuV after beta 5 at low bitrates seems quite good (I am referring here specifically to -q0). I think I may fail to abx some of my audio even at q0, if the lowpass was raised to 16khz.
Is there a way to specify lowpass with venc.exe (or can such a feature be implemented)? The quality is becoming too good for me to notice artifacts, so the lowpass is the only thing holding me back from abx. Thank you, Aoyumi.
What makes you think that Vorbis at 64 kbit/s with 16 kHz lowpass will have better quality? LAME at 128 kbit/s has 16 khz lowpass.
Pretending Vorbis to be 2x better? Insanity.
You´re asking dev for miracles.
Hi:
I don't know if this has been asked previously, but I haven't been able to find anything that clears my doubts.
I'm a bit paranoid about "stability" and the lack of something with a trusty name like "release#" has in contrast to "beta#" doesn't make me feel confident in trusting it my beloved music.
I understand vorbis is a lossy codec and that requiring it to preserve my music intact is stupid and contradictory, but maybe something less pretentious like "Can I trust this not to screw my music up even if it's called beta?" is something more reasonable.
I ask because there must be a reason why 4.51 was renamed release1 but 5 and 5.5 are still beta even if b5 is now HA's recommended encoder (or is it 5.5 now?). Also, although I don't know how much of an authority their are, RareWares doesn't host b5 compiles any longer, only b5.5.
Can someone clear this a bit for me?
Thanks in advance.
Hi:
I don't know if this has been asked previously, but I haven't been able to find anything that clears my doubts.
I'm a bit paranoid about "stability" and the lack of something with a trusty name like "release#" has in contrast to "beta#" doesn't make me feel confident in trusting it my beloved music.
I understand vorbis is a lossy codec and that requiring it to preserve my music intact is stupid and contradictory, but maybe something less pretentious like "Can I trust this not to screw my music up even if it's called beta?" is something more reasonable.
I ask because there must be a reason why 4.51 was renamed release1 but 5 and 5.5 are still beta even if b5 is now HA's recommended encoder (or is it 5.5 now?). Also, although I don't know how much of an authority their are, RareWares doesn't host b5 compiles any longer, only b5.5.
Can someone clear this a bit for me?
Thanks in advance.
Sure, I think the idea (and I can be corrected) of the AOTUV releases is that they are betas because the "libvorbis" releases are the official ones.
The tests of the AOTUV releases have been posted extensively on this site via ABX tests and it has been given the thumbs up. It is as good, and possibly slightly better than its nearest competition (LAME, Apple ACC, Nero ACC, MPC, WMA Pro) in the 128-192 range. As far as I am concerned the majority of the tme I cannot tell the difference between Vorbis q6 (approx 192) and a lossless file. My suspicion (without a systematic test) is that I would not be able to distinguish OGG q5 from a lossless file in the large majority of cases. The bottom line is that it is a top notch compression format. Any AOTUV release deserves the highest level of consideration until proven otherwise.
- Jason
So, is every "beta" stable, despite the semantical contradiction?
So, is every "beta" stable, despite the semantical contradiction?
Not incredibly important here.
So, is every "beta" stable, despite the semantical contradiction?
Not incredibly important here.
Well, that's not very helpful. I wouldn't ask if it wasn't of importance to me.
So, is every "beta" stable, despite the semantical contradiction?
Not incredibly important here.
Well, that's not very helpful. I wouldn't ask if it wasn't of importance to me.
Sorry, I am trying to explain to you that it is to your advantage to use these "beta 5.5" versions. The beta/official release won't be important until the 5.5 changes are added to the official Vorbis release. Until then Beta is better.
I think you are not understanding my question then.
I know aotuv is better. That's why I use it, as everyone else.
In my sentence "stable" should be understood as "no bugs that cause problems that spoil the result". I know lossy, by definition, "spoils" the original data in a sense. The only alternative then would be lossless.
My doubt comes purely from aoyumi's encoders nomenclature, that (with the exception of r1) are all marked/named as beta. Since beta, in general software terms, can mean unstable, buggy, not sufficiently tested, etc, I don't feel as confident using it as with something named release1, wich suggests it's stable, specially when the other released versions are all called beta, if only by contrast.
I have read about how and why beta4.51 became release1, but I couldn't find any other firm an clear statement about subsequent versions' reliability.
And that's the key point here, at least for me.
I don't have a reason to question aotuv encoders' quality and efficiency. There's enough feedback and praise here and in other places on the net to convince me. But having had a "release1" and then coming back to "beta" makes me think "hey, a new development cycle has started, you should wait for release2 for serious archiving" because, appart from quality and efficiency, I seek reliability; the confidence to encode and archive, and know all went OK.
But, just because it is called beta (after having a release name that suggested stability), I can't keep of my mind the thought that it may choke on something I throw at it and end up with something that sounds bad.
I need that reliability.
Now, I'm not asking Aoyumi to change his nomenclature or anything.
I just want someone who knows what he's talking about to make a clear statement about betaX releases reliability acording to the parameters explained above... If that's possible.
And let me repeat. It's not about how good it sounds.
I too encode most of my music at q5-q6 and don't hear the difference even though I think I have quite a good set of ears (not so good equipment, but anyway...). I know its good, it's just that I have a natural reticence to trust important things to a software labeled beta unless someone authoritative comes out and says "Yeah, you can trust this, it IS safe", or another satisfactory stance about the matter. I don't want surprises.
You should check what's recommended to use. AFAIK they still recommend beta 5 here at Hydrogen. Check Wiki and see for your self. Maybe it's time to update? (unless beta 5 is still the recommended encoder!)
I guess Aoyumi will always keep his "beta" in the name, no matter what. (Just a guess tho). So in this case, you shouldn't worry too much about the encoder being a beta.
I guess Aoyumi will always keep his "beta" in the name, no matter what. (Just a guess tho).
Yes. His posts about [a href='index.php?act=findpost&pid=421624']Beta[/a] and [a href='index.php?act=findpost&pid=447623']Release[/a].
The quality of aoTuV after beta 5 at low bitrates seems quite good (I am referring here specifically to -q0). I think I may fail to abx some of my audio even at q0, if the lowpass was raised to 16khz.
Is there a way to specify lowpass with venc.exe (or can such a feature be implemented)? The quality is becoming too good for me to notice artifacts, so the lowpass is the only thing holding me back from abx. Thank you, Aoyumi.
What makes you think that Vorbis at 64 kbit/s with 16 kHz lowpass will have better quality? LAME at 128 kbit/s has 16 khz lowpass.
Pretending Vorbis to be 2x better? Insanity.
You´re asking dev for miracles.
Because I can (almost) always ABX a lowpassed sample, even with 'distortion'. For some reason I can't easily hear 'distortion' and hence even LAME is acceptable to me at low bitrates with less agressive lowpass.
There is no way Vorbis at 64kbps will beat LAME at 128kbps for most samples, of course. Point taken. But my own point is, it's more annoying for me (and more abxable!) to hear agressive lowpass than artifacts.
aoTuV beta5.6 Pre Release (source code)
http://www.geocities.jp/aoyoume/aotuv/test (http://www.geocities.jp/aoyoume/aotuv/test)
Someone, please compile to oggenc2
aoTuV beta5.6 Pre Release (source code)
http://www.geocities.jp/aoyoume/aotuv/test (http://www.geocities.jp/aoyoume/aotuv/test)
Someone, please compile to oggenc2
I'll attempt a compile later this evening, and I'll post back when it's available.
OK, oggenc2 compiles:
Generic: http://www.rarewares.org/files/ogg/oggenc2...5.6-generic.zip (http://www.rarewares.org/files/ogg/oggenc2.85-aoTuVb5.6-generic.zip)
P3: http://www.rarewares.org/files/ogg/oggenc2...oTuVb5.6-P3.zip (http://www.rarewares.org/files/ogg/oggenc2.85-aoTuVb5.6-P3.zip)
P4: http://www.rarewares.org/files/ogg/oggenc2...oTuVb5.6-P4.zip (http://www.rarewares.org/files/ogg/oggenc2.85-aoTuVb5.6-P4.zip)
I'll not post these 'officially' at Rarewares until libvorbis 1.2.1 is officially released.
OK, oggenc2 compiles:
Wow! Many thanks john 33
john33 and Aoyumi: Thank you for your very valuable help and dedication!
Edit: added Aoyumi (I'm so ashamed)
OK, oggenc2 compiles:
Generic: http://www.rarewares.org/files/ogg/oggenc2...5.6-generic.zip (http://www.rarewares.org/files/ogg/oggenc2.85-aoTuVb5.6-generic.zip)
P3: http://www.rarewares.org/files/ogg/oggenc2...oTuVb5.6-P3.zip (http://www.rarewares.org/files/ogg/oggenc2.85-aoTuVb5.6-P3.zip)
P4: http://www.rarewares.org/files/ogg/oggenc2...oTuVb5.6-P4.zip (http://www.rarewares.org/files/ogg/oggenc2.85-aoTuVb5.6-P4.zip)
I'll not post these 'officially' at Rarewares until libvorbis 1.2.1 is officially released.
Great!!! Thanks a lot!
Thank you Aoyumi great, your contribution to the development Vorbis priceless: P
I want you to ask.
Is it possible to deactivate (optional) Point-Stereo?
Is it possible to deactivate (optional) Point-Stereo?
It's impossible now. I don't add the interface of that purpose.
OK, oggenc2 compiles:
Generic: http://www.rarewares.org/files/ogg/oggenc2...5.6-generic.zip (http://www.rarewares.org/files/ogg/oggenc2.85-aoTuVb5.6-generic.zip)
P3: http://www.rarewares.org/files/ogg/oggenc2...oTuVb5.6-P3.zip (http://www.rarewares.org/files/ogg/oggenc2.85-aoTuVb5.6-P3.zip)
P4: http://www.rarewares.org/files/ogg/oggenc2...oTuVb5.6-P4.zip (http://www.rarewares.org/files/ogg/oggenc2.85-aoTuVb5.6-P4.zip)
I'll not post these 'officially' at Rarewares until libvorbis 1.2.1 is officially released.
Great!!! Thanks a lot!
I can't get these encoders to work, I just get a failure in Foobar2000, tried the P3 and generic versions:
Source: "F:\Incoming\Talkingmakesnosense\Cloudcroft Mirror\01 - Cloudcroft Mirror.flac"
An error occured while writing to file (The encoder has terminated prematurely with code 1; please re-check parameters) : "C:\Documents and Settings\user\Desktop\Talkingmakesnosense\Cloudcroft Mirror\01 - Cloudcroft Mirror.ogg"
Additional information:
Encoder stream format: 44100Hz / 2ch / 16bps
Command line: "C:\Program Files\foobar2000 new\oggenc2.exe" -q5 - "01 - Cloudcroft Mirror.ogg"
Working folder: C:\Documents and Settings\user\Desktop\Talkingmakesnosense\Cloudcroft Mirror\
Conversion failed: The encoder has terminated prematurely with code 1; please re-check parameters
Do you not need to rename oggenc2.exe to oggenc.exe? Works fine here.
Command line: "C:\Program Files\foobar2000 new\oggenc2.exe" -q5 - "01 - Cloudcroft Mirror.ogg"
probably, you need "-o" option
parameters for fb2k custum setting (eg): --quality 5.00 --quiet - -o %d
hurrah! thanks, i'd kept the settings for venc.exe and had forgotten that i'd had to change them... all AOK
Aoyumi
I was reading some posts about testing aoTuV 5.5 with Lame and some other codecs and few people mention that .ogg vorbis cannot be compared with its rival codecs anymore.
Whether i dont know if this is truth, what are the main progressions of the aoTuV beta5.6 Pre Release compare to the previous one? In what fields will u be focusing on more and what about the pre-echo problems mentioned by other people at q5? (I'm asking because im mostly using q5 for ripping CDs).
Thanks
I was reading some posts about testing aoTuV 5.5 with Lame and some other codecs and few people mention that .ogg vorbis cannot be compared with its rival codecs anymore.
Because vorbis is better?
No lex_nasa
What i read about it, is that vorbis cannot be as competitive as it used to be in the past. Many people believe that lame had done quality improvements that vorbis couldnt follow.
Thats why id like aoyumi's opinion (but not only, people who have an opinion about vorbis quality Vs lame or .mpc id like to know it) and what are the improvements that we will see of the new release of aoTuV beta5.6
Thanks
This comment might be about the advantages of MP3 for compatability. The argument goes that since LAME is so good, why would one use Vorbis? I have never seen the argument recently that LAME has been shown to be superior to Vorbis in a blind test between 128-192 kbps.
- Jason
What do you want?
Vorbis develops one person!
That's if LAME helped in the development Vorbis
P.S.
Besides Vorbis more interesting than mp3
All the psycho-acoustic lossy compression algorithms have disadvantages in different ranges. No lossy codec is perfect.
According to my own subjective tests with very low to medium bitrates, I found that the artefacts left by Ogg Vorbis in general "sound less annoying" to me than those in MP3s, but that was already years ago...
Thanks to a great tuning by aoTuV, quality level 0 was already quite satisfying for some "Do you recognise this?" kind of listening samples.
For my mobile audio device, I found quality level 3 in general satisfying, except for very few distinct songs with rather complex effects. As MP3s, I would possibly have used at least 160 kbps and VBR, a size rate of about 3/4 for Vorbis vs. MP3 with similar subjective quality.
"Archiving quality" is a different topic. I am curious about the high-quality potential of the codecs, the amount of quality loss even at some "transparency" quality range. Here I thought that MP3 is more limited than the modern competitors, but I couldn't proove this feeling.
I was reading some posts about testing aoTuV 5.5 with Lame and some other codecs and few people mention that .ogg vorbis cannot be compared with its rival codecs anymore.
I generally think that there is not the dominant difference between codec in a bit rate of q4(128kbps).
Whether i dont know if this is truth, what are the main progressions of the aoTuV beta5.6 Pre Release compare to the previous one? In what fields will u be focusing on more and what about the pre-echo problems mentioned by other people at q5? (I'm asking because im mostly using q5 for ripping CDs).
About beta5.6, I am aimed for small revisions in the low bit rate and unification with libvorbis1.2.1. It does not have the difference with beta5.5 in q5(44.1kHz).
About the issue of pre-echo, will you show the sample which is interested in you??
Aoyumi
To be honest about the pre-echo issue is something that many people, as i read in various articles, claim that vorbis suffers in bitrates above 128. Personally i cannot hear anything. I was just curious if this is true and if you have any plans working on it. Thats why i asked.
Thanks for your reply anyway and above all thanks for your interest to keep working and developing ogg vorbis codec.
Im supporting vorbis since 2002 and i never had thoughts of changing my music into a different format. I just want it to be always competitive as the other codecs hopping to see its support spreading even more.
Thanks
"To be honest about the pre-echo issue is something that many people, as i read in various articles, claim that vorbis suffers in bitrates above 128. Personally i cannot hear anything. I was just curious if this is true and if you have any plans working on it. Thats why i asked."
I remember hearing this years ago before I started encoding Vorbis files. I have never detected any problem in the last few years that I have used this encoder. The AOTUV Vorbis encoder has been a winner for a while now. Outstanding in multiple blind tests in the 128-192 range on this site. Users vouch for it consistently as a solution for even lower bit rates. The only complaint I see is an unfortunate lack of hardware support. This argument has merit.
The argument against AOTUV Vorbis is not that Lame is better than Vorbis, it is that LAME is as good or almost as good.
- Jason
"The argument against AOTUV Vorbis is not that Lame is better than Vorbis, it is that LAME is as good or almost as good".
- Jason
I guess you got a point. I would tend to agree with that sentence you wrote.
The argument against AOTUV Vorbis is not that Lame is better than Vorbis, it is that LAME is as good or almost as good.
(http://www.hwupgrade.it/forum/images_hwu/smilies/44.gif)
Anyway LAME is
not (royalties) free.
A cd encoded with vorbis -q3 with aotuv will yield ~112kbps. For a LAME mp3 to match this would require around 160-192kbps. There is no comparison. Some music may sound just as good with -q1 at ~80kbps as an 128-160kbps mp3.
The mp3 format is a dinosaur and had its day. The only other format that comes close and perhaps beats vorbis is he-aacv2, but that's only because they added the mp3pro tech to aac. Think aac patents plus about 10 more of them due to that.
Want some samples? I can post some up too.
Hey there, Aoyumi. I wanted to say that you are doing a fantastic job with your aoTuV ogg vorbis project. This is my preferred codec for music. I don't have the space for flacs so I archive my music with 500k oggs using aoTuV b5.5.
By the way, I was wondering if some of you command-liners could help me out with a problem. I create batch files to automatically encode wave files of an album with venc and then tag the resulting files with the Tag program that comes with the Flac package.
The problem lies in foreign characters. I got quite a bit of Icelandic music, so many filenames and titles will include Icelandic characters. These characters will go to hell during batch processing, the characters get replaced by something completely different.
Does anyone here know a way around this? Like a command-line switch or an argument that will enable batch processing to correctly recognize the foreign characters?
Does anyone here know a way around this? Like a command-line switch or an argument that will enable batch processing to correctly recognize the foreign characters?
Which OS are you using? What encoding are the characters in?
If the characters are UTF8, Take a look at the --raw switch on vorbiscomment. That's what abcde uses. (Also, some unofficial versions of oggenc have a --utf8 flag; the next official version of oggenc will have the --utf8 flag too)
I think he means command-line encoders on Windows can't handle something like this:
oggenc.exe "Se cyning meteþ þone biscop.wav"
AFAIK you can't fix this on Windows without adding code to handle characters outside your codepage.
http://www.hydrogenaudio.org/forums/index....showtopic=48131 (http://www.hydrogenaudio.org/forums/index.php?showtopic=48131)
Thanks for the replies guys. It is a bummer how difficult it is to use unicode in Windows for batch processing. I guess the easiest workaround would be to drop all special characters and correct it once the batch file has finished its job.
Well, unless that script in the Flac thread can be used with venc.exe somehow.
I think he means command-line encoders on Windows can't handle something like this:
oggenc.exe "Se cyning meteþ þone biscop.wav"
AFAIK you can't fix this on Windows without adding code to handle characters outside your codepage.
True. You do have to add code to handle UTF16 (https://trac.xiph.org/changeset/15316).
The versions of oggenc available from RareWares (http://www.rarewares.org/ogg-oggenc.php) have had something like that for a few years (http://www.hydrogenaudio.org/forums/index.php?showtopic=13394).
Oggenc2 does its job well if I write the command-line text into cmd manually and execute, but if I use a batch file I face the same unicode problem as before; files with foreign characters cannot be located and tags with foreign characters get screwed up.
Ugh, what do Microsoft have against other languages than English?
Oggenc2 does its job well if I write the command-line text into cmd manually and execute, but if I use a batch file I face the same unicode problem as before; files with foreign characters cannot be located and tags with foreign characters get screwed up.
Without knowing details, I'm not sure if
cmd/u would help, or if cmd is just hopeless.
I was going to suggest PowerShell (formerly known as Monad), but if you're going to have to download something and re-learn scripting, you might as well use something decent like Perl or Python.
Ugh, what do Microsoft have against other languages than English?
Never attribute to malice that which can be adequately explained (http://en.wikipedia.org/wiki/Hanlon's_razor) by incompetence.
Ugh, what do Microsoft have against other languages than American English?
Corrected.
After more years than I care to remember, I'm still waiting for M$ to release an English version of Windows.
Cheers, Slipstreem.
True. You do have to add code to handle UTF16 (https://trac.xiph.org/changeset/15316).
The versions of oggenc available from RareWares (http://www.rarewares.org/ogg-oggenc.php) have had something like that for a few years (http://www.hydrogenaudio.org/forums/index.php?showtopic=13394).
Does it work on all Win32 platforms including Win9x?
I think he means command-line encoders on Windows can't handle something like this:
oggenc.exe "Se cyning meteþ þone biscop.wav"
AFAIK you can't fix this on Windows without adding code to handle characters outside your codepage.
Or by using an encoder that encodes from stdin like foobar2000. It has no such limitation.
What exactly is stdin? I see this mentioned all the time but have no idea what it actually is.
By the way, I've decided to settle for my music player's (XMPlay) encoding feature. It seems rather painless, create the encoder profile for aoTuV b5.5 and then click 'n encode one wave file after another. Though I will use oggenc2 for creating batch processes in the case of music that doesn't have any foreign characters.
foobar2000 used to be affected by this behaviour as well; it was only after I reported the bug that a workaround was put into place.
stdin refers to "standard input" and stdout refers to "standard output." If you use the stdout of one program and use it as the stdin of another program, then you can do stuff without using an intermediate file.
Thread split, anyone?
Unicode handling for output filenames is broken with encoders that don't support unicode themselves. I might add a special workaround for this but it will still break if output path contains non-system-codepage characters in directory names somewhere.
Sounds like the workaround might not be enough.
True. You do have to add code to handle UTF16 (https://trac.xiph.org/changeset/15316).
The versions of oggenc available from RareWares (http://www.rarewares.org/ogg-oggenc.php) have had something like that for a few years (http://www.hydrogenaudio.org/forums/index.php?showtopic=13394).
Does it work on all Win32 platforms including Win9x?
Win9x never had useful Unicode support, so no. It doesn't (and can't) work on 9x.
From the comments in the source code:
/* We only do NT4 and more recent.*/
/* It would be relatively easy to add NT3.5 support. Is anyone still using NT3? */
/* It would be relatively hard to add 9x support. Fortunately, 9x is
a lost cause for unicode support anyway. */
Besides, Microsoft stopped doing security updates for 9x on July 11, 2006 (http://www.microsoft.com/windows/support/endofsupport.mspx). I
strongly urge anyone still using Win9x to upgrade immediately. Preferably to xubuntu or similar.
foobar2000 used to be affected by this behaviour as well; it was only after I reported the bug that a workaround was put into place.
stdin refers to "standard input" and stdout refers to "standard output." If you use the stdout of one program and use it as the stdin of another program, then you can do stuff without using an intermediate file.
Thread split, anyone?
Foobar2000 seems to be a very widely used music player, I might check it out and see what all the fuzz is about.
But you lost me after the words "standard input" above. I consider myself a pretty advanced user, but the audio scene is the one place I know very little about.
Oh, and I second a thread split. I never expected the discussion would get this long. . .
standard input and standard output are not especially audio related but refer more to programming. See for example in a C/C++ book.
I don't think they refer to programming as much as OS and program design in general. (Though abandon GUI all ye who enter here.)
Standard input (stdin) = A virtual "file" from which you read stuff to process (e.g. "keyboard").
Standard output (stdout) = A virtual "file" to which you write stuff to display (e.g. "screen").
Those streams can be also redirected to/from a real file. You can for example use a originally manual program in a batch script by redirecting its stdin from some file, containing what you'd type, and its stdout to a destination file.
Even more useful is connecting the stdout of one program to stdin of another one - creating something called a "pipe". It is possible to chain practically unlimited number of programs, each doing its job. Very common in *nix world and its many simple command-line utilities.
Back to the audio encoding case above: the encoder normally reads a WAV file and processes it to a Vorbis file. When fb2k opens a pipe to it instead, it can decode any input file from the vast amout of supported file types, possibly applying whatever DSP processing user chooses, then just dump the raw PCM data to the encoder.
[never mind!]
Good work, aoyumi!
any dates for the 5.6 Release Final?
any dates for the 5.6 Release Final?
It is the time after release of libvorbis1.2.1.
(I wait for it)
@Aoyumi: Thanks for your quick answer!
libvorbis 1.2.1 (unreleased) -- "Xiph.Org libVorbis I 20080501"
* Improved robustness with corrupt streams.
* New ov_read_filter() vorbisfile call allows filtering decoded
audio as floats before converting to integer samples.
* Replaced RTP payload format draft with RFC 5215.
* Bare bones self test under 'make check'.
* Fix a problem encoding some streams between 14 and 28 kHz.
* Fix a numerical instability in the edge extrapolation filter.
* Build system improvements.
* Specification correction.
from http://svn.xiph.org/trunk/vorbis/CHANGES (http://svn.xiph.org/trunk/vorbis/CHANGES)
would anyone tell if we're close to it?
Cool! Would be no point in syncing to 1.2.1 before it's finalized. And then I can build ogg123 with replaygainsupport... Super !
aoTuV beta5.6 Released
http://www.geocities.jp/aoyoume/aotuv/ (http://www.geocities.jp/aoyoume/aotuv/)
aoTuV beta5.6 Released
http://www.geocities.jp/aoyoume/aotuv/ (http://www.geocities.jp/aoyoume/aotuv/)
New builds will be up at Rarewares either later today, or tomorrow, but I'll post here when they're available.
I tested speed of OggEnc2.exe v2.85 (libvorbis 1.2.1 RC2 [aoTuVb5.6]) from rarewares (encoding quality -q 0):
no resampling: ~20x realtime
'fast' resampling: ~16x realtime (57,8 kb/s)
'medium' resampling: ~10x realtime (57,2 kb/s)
'best' resampling: ~2x realtime (56,8 kb/s) Sloooow...
And, it looks like 'best sinc' resampler occupies ~1.3 MB, or 40% of the exe file.
I tested speed of OggEnc2.exe v2.85 (libvorbis 1.2.1 RC2 [aoTuVb5.6]) from rarewares (encoding quality -q 0):
no resampling: ~20x realtime
'fast' resampling: ~16x realtime (57,8 kb/s)
'medium' resampling: ~10x realtime (57,2 kb/s)
'best' resampling: ~2x realtime (56,8 kb/s) Sloooow...
And, it looks like 'best sinc' resampler occupies ~1.3 MB, or 40% of the exe file.
That's probably about right, but personally I prefer that to using the resampler that comes the standard oggvorbis encoders.
Anyway I must say thanks for maintaining all these codecs
Thanks once more Aoyumi!!!
Thanks John33 for the biulds you always provide!!!
Thanks once more Aoyumi!!!
Thanks John33 for the biulds you always provide!!!
::
I second that!
::
aoTuV beta5.6 Released
http://www.geocities.jp/aoyoume/aotuv/ (http://www.geocities.jp/aoyoume/aotuv/)
New builds will be up at Rarewares either later today, or tomorrow, but I'll post here when they're available.
I'm sorry, but it's going to take a little longer than I thought, there's a lot more to check through than a simple library substitution. I'll try to have this done during the course of tomorrow, but I'm away over the weekend, so if it's a little later, please bear with me.
I think he means command-line encoders on Windows can't handle something like this:
oggenc.exe "Se cyning meteþ þone biscop.wav"
AFAIK you can't fix this on Windows without adding code to handle characters outside your codepage.
Or by using an encoder that encodes from stdin like foobar2000. It has no such limitation.
or by using sane filenames
I announce aoTuV beta 5.61.
aoTuV (http://www.geocities.jp/aoyoume/aotuv/)
I announce aoTuV beta 5.61.
aoTuV (http://www.geocities.jp/aoyoume/aotuv/)
Just as well I was delayed!!! I'll try to have this done later today.
Fantastic work Aoyumi.
I announce aoTuV beta 5.61.
aoTuV (http://www.geocities.jp/aoyoume/aotuv/)
Thank you Aoyumi! Your effort is always welcome!
Aoyumi, thank you for your work!
For the interested, I have also built a statically linked Linux binary (oggenc 1.3.0 + support for FLAC & libkate):
http://artfwo.googlepages.com/oggenc-aotuvb5c.bz2 (http://artfwo.googlepages.com/oggenc-aotuvb5c.bz2)
Hey! John33, Have you any problems with compilation in windows?
In linux it seems still pitfalls free...
// G U Y S ! T H A N K F O R Y O U R W O R K
*eagerly awaiting the release on rarewares*
/me can't wait anymore and compiled vorbis library aotuv 5.61 with msvc 7.1 and icc 9.1 targeting Core 2 Duo (ICCPatched).
http://files1.rt.googlepages.com/vorbis-li...71-icc91-c2d.7z (http://files1.rt.googlepages.com/vorbis-library-msvc71-icc91-c2d.7z)
but I still waits for john's oggenc.
Also waiting for oggenc, I got a CD waiting to be the lucky number one with the new version.
/me is still waiting john's build, but I build my own oggenc 2.85 with aotuv 5.61, libogg-1.1.3, libsamplerate-0.1.4, libflac-cvs compiled with msvc 7.1 and icc 9.1 targeting Core 2 Duo (ICCPatched).
http://files1.rt.googlepages.com/oggenc2_a...71-icc91-c2d.7z (http://files1.rt.googlepages.com/oggenc2_aotuv-5.61_msvc71-icc91-c2d.7z)
Many apologies to all those who have been waiting for aoTuV5.61 builds, I've had very little time lately to deal with these.
However, seeing as it's Christmas , I've just uploaded full sets of oggenc2.85 and oggdropXPd1.9.0 builds to Rarewares.
Enjoy, and have a great Christmas, everyone.
Many apologies to all those who have been waiting for aoTuV5.61 builds, I've had very little time lately to deal with these.
However, seeing as it's Christmas , I've just uploaded full sets of oggenc2.85 and oggdropXPd1.9.0 builds to Rarewares.
Enjoy, and have a great Christmas, everyone.
Thanks!
Merry Christmas John33, merry Christmas to everyone!!!
Many Thanks for the build!!!
I announce aoTuV beta 5.61.
aoTuV (http://www.geocities.jp/aoyoume/aotuv/)
...seeing as it's Christmas , I've just uploaded full sets of oggenc2.85 and oggdropXPd1.9.0 builds to Rarewares.
Thank you, both, very much!
I have idea! John33, could you please add section for linux on ogg page of rarewares and upload there artfwo static oggenc build. I think it will be useful for many people.
----------------------------------------------------------------------------------------
Merry Christmas to everyone!!!
I also try to list them on the Wiki, when a stable binary is around:
http://wiki.hydrogenaudio.org/index.php?ti...#Linux_binaries (http://wiki.hydrogenaudio.org/index.php?title=Recommended_Ogg_Vorbis#Linux_binaries)
Rarewares changelog cites 'Multichannel code improved'. A while ago Vorbis was rather poor at multichannel encoding (compared to AAC, for example). Have I missed some major change in that direction?
don't know if anyone can make lancer patch work with latest aotuv.
http://homepage3.nifty.com/blacksword/patc...cer20061110.zip (http://homepage3.nifty.com/blacksword/patch_vorbis_lancer20061110.zip)
Chances are Lancer is still waiting for the right moment to accelerate aoTuV some more.
Can anyone confirm that the Lancer project is still alive?
Who is responsible for the CoolEdit filters at Rarewares? Are there plans to update it as well?
Who is responsible for the CoolEdit filters at Rarewares? Are there plans to update it as well?
Done, and available now. I'll update the other libraries during the course of today.
Done, and available now.
Thanks a lot, they work like a charm^^
Thanks a lot, they work like a charm^^
The other libraries have now also been updated.
Done, and available now. I'll update the other libraries during the course of today.
You have permission to ravage me sexually at your leisure.
Aoyumi made up(/juː piː/) patch (http://www.geocities.jp/aoyoume/aotuv/test) for testing.
Quote from readme:
This is patch for "aoTuV Beta 5.61". [[ Testing stage ]]
# Fixed floating point division by zero error (floor1.c).
# Improvement of the encoding speed (0`15%).
EDIT:My reference build targeting Core 2 Duo is available now.
Vorbis Library (http://files1.rt.googlepages.com/aotuv-5.61-up-library-msvc71-icc91-c2.7z)
oggenc 2.85 (http://files1.rt.googlepages.com/oggenc2-aotuv-5.61-up-msvc71-icc91-c2.7z)
You have permission to ravage me sexually at your leisure.
As you're in Canada and I'm in the UK, it looks, sadly, as though I may have to pass on your generous offer!!
Wow. When using this in foobar, when I set "Highest BPS Mode Supported" to 32, I get a 58kbps output file. When I set it to 16bits, I get a 75kbps output file! What gives?
[edit] This is true before the patch as well. q0. Source was a 161kbps vorbis file from b5.61 (32bit).
Wow. When using this in foobar, when I set "Highest BPS Mode Supported" to 32, I get a 58kbps output file. When I set it to 16bits, I get a 75kbps output file! What gives?
[edit] This is true before the patch as well. q0. Source was a 161kbps vorbis file from b5.61 (32bit).
Noise added due to dither or truncating 32->16 bits.
Noise added due to dither or truncating 32->16 bits.
Is there any way to avoid this noise during transcoding? Other than using 32bits? Is there some foobar setting?
Is there any way to avoid this noise during transcoding? Other than using 32bits? Is there some foobar setting?
Well, quantizatoin noise is unavoidable. But:
1. since foobar2000's dither implies noise-shaping
and
2. your settings are quite low (this implies low lowpass frequency)
then turning dither
on can reduce bitrate.
Rarewares changelog cites 'Multichannel code improved'. A while ago Vorbis was rather poor at multichannel encoding (compared to AAC, for example). Have I missed some major change in that direction?
I am guessing somebody figured out to how to couple the channels for 5.1 encoding and other types of multichannel input? changing the code to work with multichannel input is the easy part. Coupling the channels for multchannel and surround setups using Vorbis current configuration is the hard part. It would be nice to know who improved the code in that department so we can give credit where it's due. I removed some notes stating exactly the opposite in the wiki. It's been fixed for some time now. Thanks for bringing up that change for the community though.
Hi
I encounter 2 problems, first one:
there is a lot of clipping in vorbis from -q5 to -q10, You can see it on screenshots (in all screenshots first wave is source wav, second vorbis -q8 encoded with aoTuV 5.61).
Encoding to vorbis files that are very close to clipping gives output file with actual clipping, is there maby a way to tell encoder that if wave goes to close to clipping, have higher bitrate to avoid it.
I know You can use ReplayGain to avoid clipping, but it`s not default option, i`v made package of source and test files from -q5 to -q8 (aoTuV 5.61), the *.ogg files have calculated peak value in tags and You can simply play them in foobar2000, put volume a bit up and see how much of clipping is inside that files, for comparison You can use source file or aply ReplayGain - avoid clipping accordin to peak by track.
Test Files (http://rapidshare.com/files/180745189/clipping.7z.html)
(http://img511.imageshack.us/img511/6060/clipping1kt7.jpg)
(http://img61.imageshack.us/img61/1624/clipping1peaknc8.jpg)
(http://img201.imageshack.us/img201/7371/clipping2qu5.jpg)
Foobar2000 - ReplayGain - avoid clipping accordin to peak by track
(http://img530.imageshack.us/img530/3694/f2krg8.jpg)
Second one:
In screenshot below first is "udial.wav" second "udial.-q8.ogg" - I know that this is not audiable in normal listening volume and it does not last long but! it`s there, maby there is something that can bee done with it to fix it.
(http://img141.imageshack.us/img141/4255/artefactwf0.jpg)
One way or the other, thx for Your work Aoyumi
Does all this mean that aoTuV encoded ogg vorbis has higher volume than the source?
You noticed that your wave was clipped before you ever encoded it, right?
Hi
I encounter 2 problems, first one:
There is a lot of clipping in vorbis from -q5 to -q10. You can see it on screenshots (in all screenshots first wave is source wav, second vorbis -q8 encoded with aoTuV 5.61).
Encoding to vorbis files that are very close to clipping gives output file with actual clipping, is there maybe a way to tell encoder that if wave goes comes close to clipping that it is possible to allocate more bits in order to avoid it?. I know you can use ReplayGain to avoid clipping, but it`s not default option, i`v made package of source and test files from -q5 to -q8 (aoTuV 5.61), the *.ogg files have calculated peak value in tags and you can simply play them in foobar2000, put volume a bit up and see how much of clipping is inside that files, for comparison You can use source file or apply ReplayGain - avoid clipping according to peak by track.
Test Files
I am not going to rule out the possibility that the encoder could be causing clipping, but I find it highly unlikely this is a real serious problem. You can't "magically" throw more bits at the encoder to have it prevent clipping. The test samples aren't transient in nature just high frequency tones. You can only allocate more bits to deal with artifacts like pre-echo or microattacks. The one artifact that people have been complaining about recently is "distortion". Whether or not it's related to this is anyone's guess. I am guessing to adjust that you would have to alter some code in psy.c, but Aoyumi probably know's more about the internals then I do. Maybe the noise floor was altered slighly during the tuning process? your sample was clipped before hand so we don't even know if it's a real problem.
Hi
I encounter 2 problems, first one:
there is a lot of clipping in vorbis from -q5 to -q10, You can see it on screenshots (in all screenshots first wave is source wav, second vorbis -q8 encoded with aoTuV 5.61).
Encoding to vorbis files that are very close to clipping gives output file with actual clipping, is there maby a way to tell encoder that if wave goes to close to clipping, have higher bitrate to avoid it.
I know You can use ReplayGain to avoid clipping, but it`s not default option, i`v made package of source and test files from -q5 to -q8 (aoTuV 5.61), the *.ogg files have calculated peak value in tags and You can simply play them in foobar2000, put volume a bit up and see how much of clipping is inside that files, for comparison You can use source file or aply ReplayGain - avoid clipping accordin to peak by track.
To clean up someone else's TOS#8 mess...
OK, the udial.wav sample provided is incredibly ABXable and annoying at -q5 with the Linux static gcc4 oggenc-aotuv b5.61 linked from the wiki, it shows a weird distortion that may or may not be (EDIT: Upon further review, it apparently is) related to clipping.
foo_abx 1.3.1 report
foobar2000 v0.9.5.1
2009/01/08 23:22:53
File A: D:\clipping\udial.wav
File B: D:\clipping\udial-q5.ogg
23:22:53 : Test started.
23:24:06 : 01/01 50.0%
23:25:16 : 02/02 25.0%
23:25:34 : 03/03 12.5%
23:25:43 : 04/04 6.3%
23:25:53 : 05/05 3.1%
23:26:04 : 06/06 1.6%
23:26:23 : 07/07 0.8%
23:26:59 : 08/08 0.4%
23:27:04 : Test finished.
It's easily ABXable at -q6 with the same distortion, only less of it.
foo_abx 1.3.1 report
foobar2000 v0.9.5.1
2009/01/08 23:27:30
File A: D:\clipping\udial.wav
File B: D:\clipping\udial-q6.ogg
23:27:30 : Test started.
23:27:49 : 01/01 50.0%
23:28:02 : 02/02 25.0%
23:28:14 : 03/03 12.5%
23:28:25 : 04/04 6.3%
23:29:31 : 05/05 3.1%
23:29:54 : 06/06 1.6%
23:30:03 : 07/07 0.8%
23:30:15 : 08/08 0.4%
23:30:18 : Test finished.
----------
Total: 8/8 (0.4%)
At -q7, it's still fairly ABXable though the distortion isn't as annoying. I could probably live with it.
foo_abx 1.3.1 report
foobar2000 v0.9.5.1
2009/01/08 23:31:54
File A: D:\clipping\udial.wav
File B: D:\clipping\udial-q7.ogg
23:31:54 : Test started.
23:32:19 : 01/01 50.0%
23:32:25 : 02/02 25.0%
23:32:34 : 03/03 12.5%
23:32:50 : 04/04 6.3%
23:32:56 : 05/05 3.1%
23:33:06 : 06/06 1.6%
23:33:13 : 07/07 0.8%
23:33:23 : 08/08 0.4%
23:33:24 : Test finished.
----------
Total: 8/8 (0.4%)
At q8, it's still easly ABXable
foo_abx 1.3.1 report
foobar2000 v0.9.5.1
2009/01/08 23:34:46
File A: D:\clipping\udial.wav
File B: D:\clipping\udial-q8.ogg
23:34:46 : Test started.
23:34:58 : 01/01 50.0%
23:35:07 : 02/02 25.0%
23:36:33 : 03/03 12.5%
23:36:39 : 04/04 6.3%
23:36:46 : 05/05 3.1%
23:36:54 : 06/06 1.6%
23:36:59 : 07/07 0.8%
23:37:08 : 08/08 0.4%
23:37:11 : Test finished.
----------
Total: 8/8 (0.4%)
Still fairly ABXable at -q9.
foo_abx 1.3.1 report
foobar2000 v0.9.5.1
2009/01/08 23:38:01
File A: D:\clipping\udial.wav
File B: D:\clipping\udial-q9.ogg
23:38:01 : Test started.
23:38:23 : 01/01 50.0%
23:38:29 : 02/02 25.0%
23:38:44 : 03/03 12.5%
23:38:52 : 04/04 6.3%
23:39:00 : 05/05 3.1%
23:39:09 : 06/06 1.6%
23:39:19 : 07/07 0.8%
23:39:24 : 08/08 0.4%
23:39:26 : Test finished.
----------
Total: 8/8 (0.4%)
At -q10, it may actually be worse than -q9.
foo_abx 1.3.1 report
foobar2000 v0.9.5.1
2009/01/08 23:40:20
File A: D:\clipping\udial.wav
File B: D:\clipping\udial-q10.ogg
23:40:20 : Test started.
23:41:25 : 01/01 50.0%
23:41:32 : 02/02 25.0%
23:41:44 : 03/03 12.5%
23:41:54 : 04/04 6.3%
23:42:08 : 05/05 3.1%
23:42:21 : 06/06 1.6%
23:42:30 : 07/07 0.8%
23:42:37 : 08/08 0.4%
23:42:40 : Test finished.
----------
Total: 8/8 (0.4%)
All of this was done with replaygain off.
With replaygain on in the abx tester, I don't think I can ABX it, but there's a strange noise (sounds kinda like an alien ray gun in some cheesy low-budget sci-fi film) on both the lossless and lossy copies (WINE bug? foobar abx plugin and diskwrriter plugin applying track gain while completely disregarding the maximum gain that can be applied without causing clipping?).
Source does not have clipping, it`s on clipping threshold to test if hardware is clipping, if Your sound card is clipping on that sample, blame hardware, my sound card is audiotrak prodigy hd2 and on +3 dB - 100% volume there is no distortion of any kind and no clipping from source sample, same says Audacity, source file does not have clipping.
It`s easy to test visually in any audio editor software, like I said, purpose of this test sample is to find out if sound card adds clipping, on good sound card there is none i`m 100% positive.
I`v made one more sample file so that You maby can distinguish a sound card clipping from audio clipping encoded in vorbis.
Test sample (http://rapidshare.com/files/181327593/L.WAV.R.clipping.7z.html) -
Left channel WAV - no clipping,
Right channel aoTuV b5.61 -q8 - with clipping.
If You have good sound card than on full volume You will her clear sound from left channel and clipping (distortion) on right, if You hear distortion on both channels try to distinguish hardware clipping from clipping sample.
I am not going to rule out the possibility that the encoder could be causing clipping, but I find it highly unlikely this is a real serious problem. You can't "magically" throw more bits at the encoder to have it prevent clipping. The test samples aren't transient in nature just high frequency tones. You can only allocate more bits to deal with artifacts like pre-echo or microattacks. The one artifact that people have been complaining about recently is "distortion". Whether or not it's related to this is anyone's guess. I am guessing to adjust that you would have to alter some code in psy.c, but Aoyumi probably know's more about the internals then I do. Maybe the noise floor was altered slighly during the tuning process? your sample was clipped before hand so we don't even know if it's a real problem.
What i ment is that if sin wave peak is on threshold than encoder sholud know that and spend more time to analize the signal, and if necessary put higher bitrate on that specific peak to describe it more precise and avoid clipping, it`s like this:
(http://img122.imageshack.us/img122/5038/peakclippingox3.jpg)
of course that is only what i think is happening and it`s my guess why encoder adds clipping.
Does all this mean that aoTuV encoded ogg vorbis has higher volume than the source?
No, it means that it is no lossless codec and what goes with it, not evry sample have exactly the same value; that isn`t issue here, problem is when we have a sample that is almost clipping and it`s peak value is not described presisly but only as average value than it can happen something like this on that screenshots.
All of this was done with replaygain off.
With replaygain on in the abx tester, I don't think I can ABX it, but there's a strange noise (sounds kinda like an alien ray gun in some cheesy low-budget sci-fi film) on both the lossless and lossy copies (WINE bug? foobar abx plugin and diskwrriter plugin applying track gain while completely disregarding the maximum gain that can be applied without causing clipping?).
No, there is no wine bug, in that smple there is 19-21 kHz sin wave very close to clipping, that frequency on that volume makes some hardware to generate distortions, only thing I can say is congrats on Your hearing
For me that frequency in that sample is audiable at pre-amp volume 0,0 dB and master volume -1,2 dB.
All of this was done with replaygain off.
With replaygain on in the abx tester, I don't think I can ABX it, but there's a strange noise (sounds kinda like an alien ray gun in some cheesy low-budget sci-fi film) on both the lossless and lossy copies (WINE bug? foobar abx plugin and diskwrriter plugin applying track gain while completely disregarding the maximum gain that can be applied without causing clipping?).
No, there is no wine bug, in that smple there is 19-21 kHz sin wave very close to clipping, that frequency on that volume makes some hardware to generate distortions, only thing I can say is congrats on Your hearing
For me that frequency in that sample is audiable at pre-amp volume 0,0 dB and master volume -1,2 dB.
Actually, looking at the frequency response of the file I managed to output with foobar's diskwriter plugin, there are loud weird tones in the mids/highs that aren't in the original. I've never heard any clipping sound like that, but I don't frequently deal with signals that are almost clipping before getting amplified by 18db (equivalent to getting multiplied by approximately 63).
EDIT: To make it clear, I mean that it seems that Foobar2000's ABX tool applies track gain without looking into the maximum gain that can be applied without clipping. Since udial.wav happens to have the rare combination of "low average volume" (replaygain of +18db) and "near clipping" (peak at approximately 0.98), you get massive clipping.
I encounter 2 problems, first one:
there is a lot of clipping in vorbis from -q5 to -q10, You can see it on screenshots (in all screenshots first wave is source wav, second vorbis -q8 encoded with aoTuV 5.61).
Encoding to vorbis files that are very close to clipping gives output file with actual clipping, is there maby a way to tell encoder that if wave goes to close to clipping, have higher bitrate to avoid it.
I know You can use ReplayGain to avoid clipping, but it`s not default option, i`v made package of source and test files from -q5 to -q8 (aoTuV 5.61), the *.ogg files have calculated peak value in tags and You can simply play them in foobar2000, put volume a bit up and see how much of clipping is inside that files, for comparison You can use source file or aply ReplayGain - avoid clipping accordin to peak by track.
It is a very interesting sample.
This problem is not a thing peculiar to the aoTuV (vorbis). The problem can happen in the lossy encoding whole.
I confirmed that there were the similar problems in AAC(NeroAAC 1.3.3.0 Q0.99) and MP3(LAME 3.98.2 -b320), WMA std 9.2(q98), Musepack(mppenc1.16 Q10).
Then, about the problem to occur with it sample, you can evade it by changing lowpass filter setting (without?replaygain).
e.g.
venc.exe -q5 -lowpass=18 udial.wav
of course that is only what I think is happening and it`s my guess why encoder adds clipping.
We have just established that is not a major problem and in fact happens with most lossy encoders. It's not something directly related to the Vorbis encoder. Again it's not a real serious problem.
Not that it's likely to matter much with real samples, but perhaps the encoder should realize that there's a large amount of HF noise and adapt the lowpass accordingly.
(/me goes to try to ABX udial at a lower bitrate)
EDIT: Hopefully I'm not violating TOS#8 here, but after listening to both samples, I'm fairly confident I can't ABX a aotuv b5.61 -q 3 encode.
Is this the first sample ever that's ABXable at -q 10 but not at -q 3?
Is this the first sample ever that's ABXable at -q 10 but not at -q 3?
It is because the fixed lowpass filter setting of the default is different. Quality value does not matter.
Using lowpass it`s not the way!
Less audio killing is to have encoder thaht knows when audio is clipping and accordingly peak should be lowered to have none cliping audio.
And it should be mandatory and default.
If other encoders do the same, that`s great but it doesn`t mean that vorbis can`t be better.
...and btw I like vorbis couse there is no frequency cutoff, for me using low pass filter is out of the question, simplest solution would be implementing something like replaygain , seting highest peak value according to clipping it should be built in encoder and set as default.
...for me using low pass filter is out of the question...
Why? Can you provide ABX test results confirming that you can hear the difference between no lowpass and, say, a 16KHz lowpass in typical music content? Why make the encoder's job harder than it needs to be if you can't hear any difference... or can you?
Cheers, Slipstreem.
...for me using low pass filter is out of the question...
Why? Can you provide ABX test results confirming that you can hear the difference between no lowpass and, say, a 16KHz lowpass in typical music content? Why make the encoder's job harder than it needs to be if you can't hear any difference... or can you?
Cheers, Slipstreem.
No, I can`t but my head splits in two when I see cutoff`s on spectrum analizer, let say it`s a matter of taste
And about low pass filter; it works in this sample couse the clipping accoures in high frequency if there were clipping on vocals, guitar, etc..., than it would do any good.
Aoyumi Thank you for your work!
I really liked your recent work (aoTuV b5c [20081215]), especially the full Stereo mode for up to 160 kbps
I wish you success:)
No, I can`t but my head splits in two when I see cutoff`s on spectrum analizer, let say it`s a matter of taste
So, in audible terms, it means nothing to you. Graphs also mean nothing unless you listen with your eyes.
And about low pass filter; it works in this sample couse the clipping accoures in high frequency if there were clipping on vocals, guitar, etc..., than it would do any good.
So you don't think it makes sense to do something that has no audible effect to you personally in terms of HF content but helps the encoder to provide perceptual transparency in some problem cases? Interesting.
As you say, it's a matter of your own personal taste, but it defies logic.
Cheers, Slipstreem.
No, I can`t but my head splits in two when I see cutoff`s on spectrum analizer, let say it`s a matter of taste
So, in audible terms, it means nothing to you. Graphs also mean nothing unless you listen with your eyes.
And about low pass filter; it works in this sample couse the clipping accoures in high frequency if there were clipping on vocals, guitar, etc..., than it would do any good.
So you don't think it makes sense to do something that has no audible effect to you personally in terms of HF content but helps the encoder in some problem cases? Interesting.
Cheers, Slipstreem.
You can hear it when You don`t use low pass filter, when You use it it`s no longer there couse it`s have been cut out - this is solution to You ?
When You have clipping in lower frequencies You think cutting them out is the way to go?
Clipping is not a thing that can happen only abowe 16 kHz, the problem is not do we want or not use low pass filter or do we like it or not, problem is that vorbis gains a lot of clipping in some tracks, low pass filter can only remove clipping along with frequency, but what with clipping on the other 16 kHz You think we should cut this out too?
If someone wants to use low pass, great but even then it won`t resolve clipping problem.
Purpose of this test sample is not to correct one file, it`s for showing what is happening, and finding good solution to correct it.
If the original content in the source material that causes the problem in question is outside your normal hearing range, yes. If not, then no.
I wasn't being deliberately argumentative as your reply seems to imply. I was merely offering a perfectly logical solution for some problem cases that could be applied at all times by a given individual once their personal requirements are realistically ascertained, thus making such problem cases a non-problem ever again at any point in the future. Take it or leave it.
Cheers, Slipstreem.
Aoyumi, could you please explain what is about patch for version 5.61?
Has 5.61 any serious bugs? And what will be the next? Is it 5.62 with this fix?
Aoyumi, could you please explain what is about patch for version 5.61?
Yes. (But it needs some tests)
Has 5.61 any serious bugs? And what will be the next? Is it 5.62 with this fix?
The patch is a thing to improve the encoding speed at a low bit rate mainly.
In addition, I include the bugfix of the original libvorbis origin in the patch. It is not a serious thing. However, it is a bug.
Thx!
New source patch for vorbis decoder!
Translated with excite.co.jp
The decipherment speed of the OggVorbis file of "Q-1/-2(32kHz~48kHz)" corresponding encoded with libvorbis (AoTuV is included) is speed up. Sansa c200, iaudio M5/X5, and iPod color/Photo/Mini 2nd gen must be effective though it is Sansa E200 to confirm operation.
About 20~23% is improved in the Sansa E200 series. Moreover, it is ineffectual than the file encoded excluding a specific mode.
Source
http://www3.atwiki.jp/ao/pages/190.html (http://www3.atwiki.jp/ao/pages/190.html)
Download
http://www3.atwiki.jp/ao?cmd=upload&ac...ock_speedup.zip (http://www3.atwiki.jp/ao?cmd=upload&act=open&pageid=190&file=large_block_speedup.zip)
@Aoyumi:
Can this patch apply to ARM processors(WinCE/WM)?
Hello.
I have an approx. 100 GB collection of lossless music, Alternative rock/metal, grunge, pop, punk, psychedelic trance and drum'n'bass mostly. I encoded it with aotuv beta 5 -q6.5 and was very happy with the sound quality. But then I found out that beta 5.61 is the latest version, so I deleted the files done with b5 and encoded again with the new b5.61 (p4 version from rarewares - I have a C2D). When I listened to some songs, I felt like there's something wrong with hi-freq sounds (cymbals, hi-hats, etc) and Lane Staley's voice (when yelling). So I encoded one song (Alice in Chains - We Die Young) with beta 5 and ABX'ed it with b5.61. After I reached 3/3 score (it's not much, I know), I stopped the testing, 'cause I didn't want to waste my time with ABXing when the difference was clear to my ears. The 5.61 was slightly worse in cymbals and sharp attacks of yelling voice (-q6.5). Then I tried to download the 5.61 directly from Aoyumi's web and encoded the song with it, and it sounded kinda better, but actually I'm not sure, 'cause I didn't have more time to listen to it closely or do ABX tests. So excuse my lack of time, it will take some time for me until I'll be able to listen to my music some more, but I would like to ask Aoyumi or someone else who could know, if it is possible that beta 5.61 sounds worse at -q6.5 than beta 5, or if it could be only the P4 compile, or are my ears playing tricks on me? Because I could swear that I could hear the difference.
I have an approx. 100 GB collection of lossless music, Alternative rock/metal, grunge, pop, punk, psychedelic trance and drum'n'bass mostly. I encoded it with aotuv beta 5 -q6.5 and was very happy with the sound quality. But then I found out that beta 5.61 is the latest version, so I deleted the files done with b5 and encoded again with the new b5.61 (p4 version from rarewares - I have a C2D).
Which was a wasted, because there were no real quality improvements. Always check the change-log first on Aoyumi's website.
So excuse my lack of time, it will take some time for me until I'll be able to listen to my music some more, but I would like to ask Aoyumi or someone else who could know, if it is possible that beta 5.61 sounds worse at -q6.5 than beta 5, or if it could be only the P4 compile, or are my ears playing tricks on me? Because I could swear that I could hear the difference.
It shouldn't. 5.61 was released to fix a minor bug that to my knowledge is not related to any specific quality improvements. Some major changes came from 5.5 -> 5.6. There was some more tuning done to the impulse short blocks. I mean it could be related to a bug in the encoder that is possible. It could have something to do with the adjusted thresholds on the impulse short blocks also. Anything is possible. It's hard to know what you are referring to if you do not post an ABX log and provide us with some samples that would make things easier.
OK, I'll post ABX log and samples as soon as I have some time. It will however take some time, I'm afraid...
Hi,
I tried some ABXing, but only thing I was able to ABX was aoTuV b5.61 (oggenc2.85 P4) at -q6,5 to lossless wav. I tried to ABX oggenc2.85 P4 (aotuv b5.61 -q6,5) to venc (aotuv b5 -q6.5) but I could'n notice any difference. So I'm sorry for the confusion, perhaps originally when I encoded my collection to b5.61 I screwed something up, now I don't hear any difference between b5 and b5.61 at all. Here's the Foobar2000's ABX log of aotuv b5.61 vs wav:
foo_abx 1.3.3 report
foobar2000 v0.9.6.1
2009/02/04 12:18:11
File A: D:\Music\new\WAV\02 - Dam That River.wav
File B: D:\Music\new\WAV\02 - Dam That River.ogg
12:18:11 : Test started.
12:19:02 : 01/01 50.0%
12:21:26 : 02/02 25.0%
12:21:52 : 03/03 12.5%
12:22:42 : 04/04 6.3%
12:23:32 : 05/05 3.1%
12:24:41 : 06/06 1.6%
12:25:21 : 07/07 0.8%
12:26:00 : 07/08 3.5%
12:27:24 : 08/09 2.0%
12:28:54 : 09/10 1.1%
12:29:43 : 10/11 0.6%
12:30:24 : 11/12 0.3%
12:30:27 : Test finished.
----------
Total: 11/12 (0.3%)
So sorry again, b5.61 sound the same at q6,5 as b5 to me now. Still I can't get this thing out of my head, 'cause I know what I heard a week ago, I will investgate further to find out what was wrong.
Bye!
I have an approx. 100 GB collection of lossless music, Alternative rock/metal, grunge, pop, punk, psychedelic trance and drum'n'bass mostly. I encoded it with aotuv beta 5 -q6.5 and was very happy with the sound quality. But then I found out that beta 5.61 is the latest version, so I deleted the files done with b5 and encoded again with the new b5.61 (p4 version from rarewares - I have a C2D).
Which was a wasted, because there were no real quality improvements. Always check the change-log first on Aoyumi's website.
So excuse my lack of time, it will take some time for me until I'll be able to listen to my music some more, but I would like to ask Aoyumi or someone else who could know, if it is possible that beta 5.61 sounds worse at -q6.5 than beta 5, or if it could be only the P4 compile, or are my ears playing tricks on me? Because I could swear that I could hear the difference.
It shouldn't. 5.61 was released to fix a minor bug that to my knowledge is not related to any specific quality improvements. Some major changes came from 5.5 -> 5.6. There was some more tuning done to the impulse short blocks. I mean it could be related to a bug in the encoder that is possible. It could have something to do with the adjusted thresholds on the impulse short blocks also. Anything is possible. It's hard to know what you are referring to if you do not post an ABX log and provide us with some samples that would make things easier.
I think most of the work done on aoTuV is only used below -q5.
It'd be nice if Aoyumi or someone else who would know could comment on whether aoTuV b5.5 -q 6.5 encodings should be different from aoTuV b 5.61 -q 6.5 encodings.
[/quote]
I think most of the work done on aoTuV is only used below -q5.
It'd be nice if Aoyumi or someone else who would know could comment on whether aoTuV b5.5 -q 6.5 encodings should be different from aoTuV b 5.61 -q 6.5 encodings.
[/quote]
For a start one could encode a .wav in to two files, one being aoTuV b5.5 -q 6.5, one aoTuV b 5.61 -q 6.5.
Then decode back to .wav (with the same decoder) and then open it in cooledit or such and subtract one file from the other.
(in cooledit that means opening file1, inverting it, opening file2, select the entire file2 and copy it. Then mix paste into file1, at 100 % volume)
If there are differences between the files, you can listen to them now. If you hear and see nothing, you have no difference.
This is also a nice way to check what exactly a lossy codec leaves behind (compare encoded file against original wav).
If there are differences between the files, you can listen to them now. If you hear and see nothing, you have no difference.
This is also a nice way to check what exactly a lossy codec leaves behind (compare encoded file against original wav).
... or you could just ABX the original file and compare to the two encoded ones. Welcome to HA. Please read the TOS #8.
I think most of the work done on aoTuV is only used below -q5.
It'd be nice if Aoyumi or someone else who would know could comment on whether aoTuV b5.5 -q 6.5 encodings should be different from aoTuV b 5.61 -q 6.5 encodings.
They shouldn't be! there was no tuning done to the encoder just bugfixes!. One can't rule out the possibility this is related to a bug or the fact that it maybe nothing at all. You are right most of the tunings are done for -q levels below 5 though. That's were they can really make an impact. A lot of it has to do with adjusting the ATH on impulse short blocks and normalizing the noise in the MDCT routines. Those are the changes he usually makes to the source code when he tweaks it.
Can this patch apply to ARM processors(WinCE/WM)?
It is not a general-purpose patch for ARM processors.
The patch is a thing for specific CPU(SoC)'s based on Rockbox interface.
It'd be nice if Aoyumi or someone else who would know could comment on whether aoTuV b5.5 -q 6.5 encodings should be different from aoTuV b 5.61 -q 6.5 encodings.
The difference between 5.61 and 5.5 is very small at the high bitrate.
Please do not mind it.
[quote name='HotshotGG' date='Feb 5 2009, 14:23' post='613141']
... or you could just ABX the original file and compare to the two encoded ones. Welcome to HA. Please read the TOS #8.
I was not talking about a quality comparison. Just checking if there is any differences in the files at all. If there were, one should of course do ABX. Of course one could also use some file comparison tools but then maybe there are changes in the header which mess up the results.
I know I should have, and hope my lawyer doesn' read this: but who does ever read TOS anyway ;-)
Can this patch apply to ARM processors(WinCE/WM)?
It is not a general-purpose patch for ARM processors.
The patch is a thing for specific CPU(SoC)'s based on Rockbox interface.
Testing your patch, I see that it doesn't seem to impact most files, so I assume only lower quality settings are accelerated? I'm a bit hesitant to commit IRAM to buffers that only a minority of files will actually use. Is it possible to reuse IRAM allocated for higher quality settings then? My knowledge of Tremor's low bitrate features is almost non-existent.
----
In the future, consider posting patches to our tracker:
http://www.rockbox.org/tracker/index.php?type=4 (http://www.rockbox.org/tracker/index.php?type=4)
Its much easier for me to find patches that way.
Testing your patch, I see that it doesn't seem to impact most files, so I assume only lower quality settings are accelerated?
Your thought is right. The benchmark is as follows for your information.
original code -> patch code
vorbis_032.ogg (aoTuV r1 -q-2)
227.46% realtime -> 284.53% realtime
vorbis_048.ogg (aoTuV r1 -q-1)
223.19% realtime -> 278.27% realtime
vorbis_064.ogg (aoTuV r1 -q0)
277.13% realtime -> 277.13% realtime
I'm a bit hesitant to commit IRAM to buffers that only a minority of files will actually use. Is it possible to reuse IRAM allocated for higher quality settings then?
It is possible technically. If a reason to need a space of IRAM is made new, it should be changed.
In the future, consider posting patches to our tracker:
http://www.rockbox.org/tracker/index.php?type=4 (http://www.rockbox.org/tracker/index.php?type=4)
Its much easier for me to find patches that way.
Thank you for a suggestion.
aoTuV Beta5.7 released
- Improvement of the encoding speed of low bitrate mode. (Around 11% at the max)
- Fixed some bugs.
URL: http://www.geocities.jp/aoyoume/aotuv/ (http://www.geocities.jp/aoyoume/aotuv/)
aoTuV Beta5.7 released
- Improvement of the encoding speed of low bitrate mode. (Around 11% at the max)
- Fixed some bugs.
URL: http://www.geocities.jp/aoyoume/aotuv/ (http://www.geocities.jp/aoyoume/aotuv/)
I picked this up last evening (UK time ) but, unfortunately there are a couple of compile errors in the vorbis libs preventing me from posting new compiles. Aoyumi has been advised of this and I await his reply.
If someone can't wait for oggenc's tagging function when ripping with EAC, vorbiscomment or Tag might be useful.
Here's an example for EAC + venc + vorbiscomment.
"Use file extension": .ogg
"Program, including path, used for compression": C:\WINDOWS\system32\cmd.exe
"Add ID3 tag": off
"Additional command-line options":
/c C:\"Program Files"\aoTuV\venc.exe -q2 %s %d && C:\"Program Files"\vorbiscomment\vorbiscomment.exe -a %d -t "ARTIST=%a" -t "ALBUM=%g" -t "TRACKNUMBER=%n/%x" -t "TITLE=%t" -t "DATE=%y" -t "GENRE=%m" -t "COMMENT=%e"
or
/c ""C:\Program Files\aoTuV\venc.exe" -q2 %s %d && "C:\Program Files\vorbiscomment\vorbiscomment.exe" -a %d -t "ARTIST=%a" -t "ALBUM=%g" -t "TRACKNUMBER=%n/%x" -t "TITLE=%t" -t "DATE=%y" -t "GENRE=%m" -t "COMMENT=%e""
If you want to use field names other than Xiph's minimal list (http://www.xiph.org/vorbis/doc/v-comment.html), -t "TRACKNUMBER=%n/%x" could be changed for -t "TRACKNUMBER=%n" -t "TOTALTRACKS=%x".
/c C:\"Program Files"\aoTuV\venc.exe -q2 %s %d && C:\"Program Files"\vorbiscomment\vorbiscomment.exe -a %d -t "ARTIST=%a" -t "ALBUM=%g" -t "TRACKNUMBER=%n" -t "TOTALTRACKS=%x" -t "TITLE=%t" -t "DATE=%y" -t "GENRE=%m" -t "COMMENT=%e"
/c ""C:\Program Files\aoTuV\venc.exe" -q2 %s %d && "C:\Program Files\vorbiscomment\vorbiscomment.exe" -a %d -t "ARTIST=%a" -t "ALBUM=%g" -t "TRACKNUMBER=%n" -t "TOTALTRACKS=%x" -t "TITLE=%t" -t "DATE=%y" -t "GENRE=%m" -t "COMMENT=%e""
-t "FREEDB=%f" -t "CRC=%b" might be added, too.
"Fixed some bugs." - how much more bugs there can be? a bit more info would be much aprichiated?
Constant changes, its very good to improve encoder and i`m thankful for it, but on the other hand it`s good to know that what you have is concrete!
I picked this up last evening (UK time ) but, unfortunately there are a couple of compile errors in the vorbis libs preventing me from posting new compiles. Aoyumi has been advised of this and I await his reply.
I revised it to be able to compile it in MS-VC Compiler.
"Fixed some bugs." - how much more bugs there can be? a bit more info would be much aprichiated?
Constant changes, its very good to improve encoder and i`m thankful for it, but on the other hand it`s good to know that what you have is concrete!
It is the floating point exception and memory access violation which can happen in the limited situation.
They usually hardly influence an encoding result.
I picked this up last evening (UK time ) but, unfortunately there are a couple of compile errors in the vorbis libs preventing me from posting new compiles. Aoyumi has been advised of this and I await his reply.
I revised it to be able to compile it in MS-VC Compiler.
I have the fix now and will be recompiling and uploading later today.
"Fixed some bugs." - how much more bugs there can be? a bit more info would be much aprichiated?
Constant changes, its very good to improve encoder and i`m thankful for it, but on the other hand it`s good to know that what you have is concrete!
It is the floating point exception and memory access violation which can happen in the limited situation.
They usually hardly influence an encoding result.
Roger that, hx for reply
A full set of aoTuVb5.7 compiles is now available at Rarewares.
A full set of aoTuVb5.7 compiles is now available at Rarewares.
...and a big "thank you" for John33 and Aoyumi is available here!
Can anyone upload linux binaries?
Big thanks to Aoyumi and John33 .
I sure wish ogg vorbis getting more hardware support.
::
To Aoyumi and John33 - thank you.
::
Hi,
thanks fpr yet another update^^ Keep up the good work.
HF, Clobon
Big thanks to Aoyumi and John33 .
I sure wish ogg vorbis getting more hardware support.
At least there's Rockbox!
Thank you very much guys
It is ALWAYS appreciate your efforts and time spending on ogg vobis project. I'm always happy everytime i see another release comin out
Thanks again
Can anyone upload linux binaries?
Hi! Here is a static one. I've missed the release day as usual!
oggenc-aotuvb5d.bz2 (http://artfwo.googlepages.com/oggenc-aotuvb5d.bz2)
Thanks Aoyumi for the great fork, thanks john33 for the Windows binaries, and thanks artfwo for the GNU/Linux binaries. I am an advocate of the Vorbis format and you all three help a lot to spread a better free (as in freedom) tool.
Oh yeah, Vorbis rules; thanx to everyone involved!
I sure wish ogg vorbis getting more hardware support.
There are a lot of DAPs that can play Vorbis nowadays. One should look beyond the iPod to really see the light
I am listening to AoTuv 5.7 -q5 files on my Cowon D2 right now....
Hi
I sure wish ogg vorbis getting more hardware support.
There are a lot of DAPs that can play Vorbis nowadays. One should look beyond the iPod to really see the light
I am listening to AoTuv 5.7 -q5 files on my Cowon D2 right now....
So... The D2 hasn't got the bad habit of annoyingly bad Ogg playback?
My iAudio7 sounds awful when playing back Ogg (~Q7 ).
Sorry for OT. HF, Clobon
Aoyumi, I was looking through the old XIPH mailing lists and I read that the xiph team wanted you to become the official maintainer for Vorbis but you declined the offer. I was wondering what was the reason behind this as you would be doing the same thing you are right now but the source would be accessible to more public (like linux distributions, game developers, etc etc who right now use the stock vorbis code). I don't think the changes right now in your branch might take a very long time to be merged back if at all. I know you must have a reason but I was just confused.
Thanks
Aliumalik
I was wondering the same thing.
Aoyumi, I was looking through the old XIPH mailing lists and I read that the xiph team wanted you to become the official maintainer for Vorbis but you declined the offer. I was wondering what was the reason behind this as you would be doing the same thing you are right now but the source would be accessible to more public (like linux distributions, game developers, etc etc who right now use the stock vorbis code). I don't think the changes right now in your branch might take a very long time to be merged back if at all. I know you must have a reason but I was just confused.
Thanks
As for time, I am limited. I must throw something away if I undertake it.
So... The D2 hasn't got the bad habit of annoyingly bad Ogg playback?
My iAudio7 sounds awful when playing back Ogg (~Q7 ).
Sorry for OT. HF, Clobon
No. They have fixed that in the D2.
aoTuV experiment BS1 [for tester] released in test page.
http://www.geocities.jp/aoyoume/aotuv/test (http://www.geocities.jp/aoyoume/aotuv/test)
Hello rt87. Is this new build aimed at handling problem samples mentioned in this (http://www.hydrogenaudio.org/forums/index.php?showtopic=70442) thread?
Hello rt87. Is this new build aimed at handling problem samples mentioned in this (http://www.hydrogenaudio.org/forums/index.php?showtopic=70442) thread?
Don't know.
release notice (http://www2.atword.jp/aooa/2009/03/31/aotuv-bs1/) translated by excite.jp:
The new test version of aoTuV was up-loaded to the test page.
The nature that especially put up the hand about the problem by the mistake of the block switching of the encoder did not exist at all though some problems peculiar to a current Vorbis encoder remained. Because this part is a very slight part in the patent surroundings. I did not want to be related for the comment to refer the patent to exist also in the source code of foundation if possible. However, because the artifact caused by this problem stands out though there are not a lot of ratios where the problem around the block switching is caused, the mistake is not found in the part it that should mend.
The problem of causing it with some samples was reduced as a result of this trial and error by enhancing the range where the change in a rough algorithm is not accompanied, and it was possible to cancel it. The average bit rate's rising a little, the encode time has expanded a little. I think a problem all already-known to be a trade-off not bad as for the improvement though no made translation.
Please inform me though it doesn't think the problem to be if something a peculiar problem is caused. The change point of this version has the influence in all the encode modes.
I am quite convinced that it indeed has to do something with the samples in that thread! Let us wait and watch.
Hello, I'm using CDex 1.70 beta 2 on Vista 64 SP1. So far I've been using aoTuVb5.5 without any problems. But as soon as I install aoTuVb5.7 the OGG option disappears from the list of encoders in CDEx. When I put back the 5.5 files, it's ok again.
Did anyone notice that problem ? Any solution ?
Thanks in advance
Mirko
You may need the libmmd.dll (10.1 version) from the 'Others' page at Rarewares.
But as soon as I install aoTuVb5.7 the OGG option disappears from the list of encoders in CDEx. When I put back the 5.5 files, it's ok again.
Did anyone notice that problem ? Any solution ?
aoTuV b5.5 depends on MSVCRT.DLL but aoTuV b5.7 requires MSVCR90.dll. Install Microsoft Visual C++ 2008 Redistributable.
Thanks a lot, now it works
But as soon as I install aoTuVb5.7 the OGG option disappears from the list of encoders in CDEx. When I put back the 5.5 files, it's ok again.
Did anyone notice that problem ? Any solution ?
aoTuV b5.5 depends on MSVCRT.DLL but aoTuV b5.7 requires MSVCR90.dll. Install Microsoft Visual C++ 2008 Redistributable.
But as soon as I install aoTuVb5.7 the OGG option disappears from the list of encoders in CDEx. When I put back the 5.5 files, it's ok again.
Did anyone notice that problem ? Any solution ?
aoTuV b5.5 depends on MSVCRT.DLL but aoTuV b5.7 requires MSVCR90.dll. Install Microsoft Visual C++ 2008 Redistributable.
Yep, I forgot that one!! Thanks.
But as soon as I install aoTuVb5.7 the OGG option disappears from the list of encoders in CDEx. When I put back the 5.5 files, it's ok again.
Did anyone notice that problem ? Any solution ?
aoTuV b5.5 depends on MSVCRT.DLL but aoTuV b5.7 requires MSVCR90.dll. Install Microsoft Visual C++ 2008 Redistributable.
Supplement:
The aoTuV beta 5.7 DLL in my page does not need
additional DLLs.
This depends on the difference of the compiler (setting) simply.
Supplement:
The aoTuV beta 5.7 DLL in my page does not need additional DLLs.
This depends on the difference of the compiler (setting) simply.
Oops. I should mention explicitly that my post was about rarewares compile.
What does "BS1" mean? And does it mean next aotuv version will be a "Aotuv BS1" not a "beta 6"?
What does "BS1" mean?
maybe "BS1" mean "Block Switching (test 1 ???)"
What does "BS1" mean?
maybe "BS1" mean "Block Switching (test 1 ???)"
That's correct.
And does it mean next aotuv version will be a "Aotuv BS1" not a "beta 6"?
Probably next version will become beta 5.x or beta 6.
If it really fixes the Block Switching issues I think Beta 6 is more appropriated than beta 5.x, because if it really achieve this IMHO it will be the biggest quality improvement for vorbis since aoTuV Beta 2. I didn't test BS1, so I have no clue at all actually. When you will be ready to release a "RC" for Beta 6, ring my bell, I will test it. I don't really want to waste my time, testing all the possible in between versions actually. I am not a low bitrate fan, so IMHO the biggest thing to fix is to make q6 transparent to compete with Nero AAC. From what I heard fixing Block Switching will affect all bitrates anyway, so if it happens, it will be a major update. The biggest unknow for me is to known if you are doing a quick hack like old GT version or if you have really decided to fix it once for good (because in the beginning you said you will not fix it now, so I was surprised that BS1 poped up so quickly), that's why I didn't test BS1, I never like GT Tuned version, so I don't really want the same kind of quick patch (cheating with bitrate) for block switching.
so IMHO the biggest thing to fix is to make q6 transparent to compete with Nero AAC. From what I heard fixing Block Switching will affect all bitrates anyway, so if it happens, it will be a major update. The biggest unknow for me is to known if you are doing a quick hack like old GT version or if you have really decided to fix it once for good (because in the beginning you said you will not fix it now, so I was surprised that BS1 poped up so quickly), that's why I didn't test BS1, I never like GT Tuned version, so I don't really want the same kind of quick patch (cheating with bitrate) for block switching.
The current test version does not solve the problem of all types(you showed it). It solves the problem of the specific pattern mainly by expanding the search range of the block switching (different from GT version).
The better solution that I think of now bumps in an existing patent surely. It is not preferable for Vorbis.
What concerns myself, Vorbis failure in the test became a bolt from the blue. I am thinking of fallback to mp3
The problem I highlighted is not new at all, vorbis has shined in some Roberto's listening test despite the block switching issue. So on average music, vorbis is still competitive, specially at 128Kbps & below, where every codec has holes anyway. The problem is that it is a codec that has some holes even at high bitrate, think of it as a colander. MP3 is not better qualitywise, I could add several samples where it fails if I had any interest in MP3, but it has the advantage that it is a big standard, with universal support. Personnaly 2 weeks after my test, I moved back to lossy|flac. I was quite happy with vorbis when I didn't knew anything about block switching If I would be sure vorbis had a developper for high bitrates maybe I wouldn't have switched, but I know Monty doesn't care much anymore for vorbis, he only fixes some bugs here & there, but nothing that really improves audio quality & I know Aoyumi is mainly interested in low bitrate. In the beginning I had some hope that I would help aoyumi fixing this problem, but when I realised that this was the same issue that Garf tried to fix several years ago. I realised it would most likely never be fixed. Vorbis is very suited for low/mid bitrates streaming with icecast or for low/mid bitrates audio coupled with theora, so if you are a webmaster then vorbis is a great option. There it really shines as this is what it is built for. But for CD backup it is not very suited, it fails to bring transparency at high bitrate on electronic & live recordings which is not acceptable for an audiophile.
I think that many people who don't do listening test for themselves, mixed pre-echo & block switching (I did) & thought that aotuv beta 2 had solved all vorbis problems. That's why aotuv becomed quite popular when at the same time mpc was dying. Sadly if aotuv beta 2 has improved pre-echo a lot, it didn't affect the block switching issue much. I only realized it lately. Happyly enough I had already switched to lossless & deleted all my vorbis files several years ago personnaly. It was a bit of noltalgia to retry it, but I am not a romantic, I left
Little quiet in the ogg vorbis forum
I was wondering if Aoyumi is planning to release any new version of his code or if he is working on something...
A bit OT: And I wonder if Ogg Vorbis will get a boost ever again, especially now Firefox will support it natively. It's so sad to see industry are adding to hardware aac/mp4 support instead of, or adding too ogg/vorbis. I suppose it's due to the absence of a collective focussing forces.
Could somebody compile a win64 copy of the latest aoTuV, I would like to see if there are any gains in speed as have been seen in LAME and MPC's 64bit editions thanks to newer compiler optimizations.
and Alexxander, theres a good reasion (good in the eyes of the riaa/mpaa) for not supporting ogg, unlike AAC/MP4 ogg isnt really built to have any kind of DRM used on it, and we all know how the riaa/mpaa/exct love their DRM.......
What is block switching, forgive my ignorance?
A bit OT: And I wonder if Ogg Vorbis will get a boost ever again, especially now Firefox will support it natively. It's so sad to see industry are adding to hardware aac/mp4 support instead of, or adding too ogg/vorbis. I suppose it's due to the absence of a collective focussing forces.
Well, despite the industry's seeming move to AAC/MP4, I see Ogg Vorbis gaining ground with game developers.
I didn't know that Firefox support Ogg Vorbis natively??
Sadly if aotuv beta 2 has improved pre-echo a lot, it didn't affect the block switching issue much
If there are block switching issue problems and I haven't encountered many of them. Some cannot be fixed for one reason alone. There are some things you cannot adjust in the source code without running into patents. This happens to be one of them. A customized window function was also designed in order to avoid any patents in regard to that area.
But for CD backup it is not very suited, it fails to bring transparency at high bitrate on electronic & live recordings which is not acceptable for an audiophile
Do you have any listening tests to backup these claims? I use FLAC to archive my CD's, but I use Vorbis still for HD and streaming purposes. It seems adequate enough in the listening tests that I have done around -q 8, which is overkill if you ask some people.
What is block switching, forgive my ignorance?
It's a mechanism that the new lossy codecs AAC and Vorbis have a reliance upon heavily, because in the engineering world they are called frequency domain coders. The problem with frequency domain coders is sometime they fail to provide adequate time resolution on transients (short impulsive audio signals) and that's why you need to switch between long blocks (better frequency resolution) and short blocks (better time resolution). A block is nothing, but a set of PCM audio samples that are a multiple of 2.
Well, despite the industry's seeming move to AAC/MP4, I see Ogg Vorbis gaining ground with game developers.
I didn't know that Firefox support Ogg Vorbis natively?
Vorbis and Theora will be supported natively within Firefox 3.5 the newest release. This has a lot to do with the new <video> and <audio> tags in HTML 5 spec that are part of Firefox 3.5. The only problem is that Theora needs some more work to get it somewhat on par with H.264 that's what the "Thusnelda" branch is for. Dailymotion the popular video site has already started releasing their stuff in both Vorbis and Theora. Monty got a nice grant from the Firefox and Wikimedia people of $100,000 to work on Theora. He job right now is with Red Hat doing just that.
Vorbis and Theora will be supported natively within Firefox 3.5 the newest release. This has a lot to do with the new <video> and <audio> tags in HTML 5 spec that are part of Firefox 3.5. The only problem is that Theora needs some more work to get it somewhat on par with H.264 that's what the "Thusnelda" branch is for. Dailymotion the popular video site has already started releasing their stuff in both Vorbis and Theora. Monty got a nice grant from the Firefox and Wikimedia people of $100,000 to work on Theora. He job right now is with Red Hat doing just that.
Oh, you're talking about Fx3.5 ... I'm still staying away from that because it's not yet RC
As for Theora... why aren't they using Dirac?
There are some things you cannot adjust in the source code without running into patents. This happens to be one of them. A customized window function was also designed in order to avoid any patents in regard to that area.
OK, it's not appliable in the official Vorbis encoder, then. But what about an "underground" version ?
Does it could break the compatibility with the official decoder ?
For lancer resurrection (from mpg123 changelog):
Change log:
New and improved SSE optimizations! For x86-64, too! Also AltiVec! Fast float output! Faster stereo!
Finally, this should put mpg123 into the efficiency-leading position on current hardware!
Thanks go out to Taihei Monma for pushing lots of new assembler code.
Uhmm...
A bit OT: And I wonder if Ogg Vorbis will get a boost ever again, especially now Firefox will support it natively. It's so sad to see industry are adding to hardware aac/mp4 support instead of, or adding too ogg/vorbis. I suppose it's due to the absence of a collective focussing forces.
Well, despite the industry's seeming move to AAC/MP4, I see Ogg Vorbis gaining ground with game developers.
The more documentation & standardization the easier (or not so impossible) & more worthwhile it is to implement a technology, I suspect that is the reason you see few hardware devices with OGG Vorbis support.
For game developers all they have to do is encode their files in the free format and make that little extra bit of profit.
There are some things you cannot adjust in the source code without running into patents. This happens to be one of them. A customized window function was also designed in order to avoid any patents in regard to that area.
OK, it's not appliable in the official Vorbis encoder, then. But what about an "underground" version ?
Does it could break the compatibility with the official decoder ?
Compatibility does not fail.
It is completely a problem of the encoder side. It is not a problem of a format.
As for Theora... why aren't they using Dirac?
You know that's good question and I am not really sure to be honest with you. Maybe there aren't enough tools avaliable to start using it. Firefox 3.5 has an implementation of FFMPEG in it to do on the fly transcoding if I am not mistaken also.
There are some things you cannot adjust in the source code without running into patents. This happens to be one of them. A customized window function was also designed in order to avoid any patents in regard to that area.
OK, it's not appliable in the official Vorbis encoder, then. But what about an "underground" version ?
Does it could break the compatibility with the official decoder ?
Compatibility does not fail.
It is completely a problem of the encoder side. It is not a problem of a format.
What about releasing an "underground"/secret version of the encoder which does not avoid the patents?
What about releasing an "underground"/secret version of the encoder which does not avoid the patents?
... and risk getting sued six ways to Sunday by the MPEG consortium and loss all credibility surrounding the project?. The specific problems that arise from this are rare. The AoTuV tunings will eventually get merged into the official brance after the next release. It's probably not a wise to do that also.
What about releasing an "underground"/secret version of the encoder which does not avoid the patents?
... and risk getting sued six ways to Sunday by the MPEG consortium and loss all credibility surrounding the project?. The specific problems that arise from this are rare. The AoTuV tunings will eventually get merged into the official brance after the next release. It's probably not a wise to do that also.
AFAIK the LAME encoder uses patented methods as well, and they get away with it by only distributing the source code. Apparently, the source code is only a description of the patented method, and the description is publicly available anyway. Of course, merging the change into the official version would probably be a bad idea.
AFAIK the LAME encoder uses patented methods as well, and they get away with it by only distributing the source code. Apparently, the source code is only a description of the patented method, and the description is publicly available anyway. Of course, merging the change into the official version would probably be a bad idea.
Well that's what's planned. AoTuV stand alone is great softare. It would be even better see it merged into the official Vorbis branch. That's what's going to happen with the next official release of libvorbis, because the demand is so high. It coincides with the beta release of the Thusnelda encoder as well.
What about releasing an "underground"/secret version of the encoder which does not avoid the patents?
... and risk getting sued six ways to Sunday by the MPEG consortium and loss all credibility surrounding the project?. The specific problems that arise from this are rare. The AoTuV tunings will eventually get merged into the official brance after the next release. It's probably not a wise to do that also.
AFAIK the LAME encoder uses patented methods as well, and they get away with it by only distributing the source code. Apparently, the source code is only a description of the patented method, and the description is publicly available anyway. Of course, merging the change into the official version would probably be a bad idea.
Exactly. I have in mind something like FLAKE, an unofficial implementation on an open source project.
This "Barelly legal Vorbis" encoder could be hosted in a Russian (or DVD Jon (http://nanocr.eu/)) website and NOT integrated in the official sources (of course).
Then we can involve "compiles freaks" (as LAME (http://lame.sourceforge.net/links.php#Binaries) or XviD (http://www.koepi.info/) does) for binaries.
EDIT
OK, an idea for the name: Greebo (http://en.wikipedia.org/wiki/Greebo), the Discworld's Nanny OGG's murderous cat.
He is a foul-tempered one-eyed grey tomcat whose owner, Nanny Ogg, insists against all the evidence that he is a sweet, harmless kitten. In the course of the books, he has killed two vampires, eating at least one of them in the novel Witches Abroad:
The bat squirmed under his claw. It seemed to Greebo's small cat brain that it was trying to change its shape, and he wasn't having any of that from a mouse with wings on.
And in Maskerade, Magrat recalls when Greebo once killed an elk.
In Lords and Ladies, Greebo's overall attitude is best described in an allusion to Schrödinger's cat:
Greebo had spent an irritating two minutes in that box. Technically, a cat locked in a box may be alive or it may be dead. You never know until you look. In fact, the mere act of opening the box will determine the state of the cat, although in this case there were three determinate states the cat could be in: these being Alive, Dead, and Bloody Furious.
Shawn dived sideways as Greebo went off like a Claymore mine.
"Don't worry about him," said Magrat dreamily, as the elf flailed at the maddened cat. "He's just a big softy."
This could have many meanings beside: OGG, cat, vampires killer (aka Vorbis, Hydrogenaudio, patents killer), etc..
(http://patrick.sutormoz.ru/Nanny_Ogg's_Cookbook/Nanny_and_Greebo.jpg)(http://upload.wikimedia.org/wikipedia/en/3/37/Greebo.jpg)(http://www.nt.ntnu.no/users/leifolav/Greebo.jpg)
(http://profile.ak.facebook.com/object3/1973/43/n39735699108_5785.jpg)(http://www.paulkidby.com/images/mousemats/mm-greebo1.jpg)
Technical question: could LAME bs code be used into "Greebo" ?
Another idea: is it possible to separate the bs algorithm from the encoder ?
If so, it could be en external library that may be exchangable between various codec's encoder engines...
Technical question: could LAME bs code be used into "Greebo" ?
It is impossible unless somebody remodels the cord. And the somebody tunes it up and must test it.
Another idea: is it possible to separate the bs algorithm from the encoder ?
If so, it could be en external library that may be exchangable between various codec's encoder engines...
That there is the person who is going to carry it out is a problem.
If I think, probably it does not balance with labor.
Dear Aoyumi, could you please say some words about future integration aotuv into libvorbis 1.3.0.
What will be the base? Will be it beta 5.7 code or anything else?
Dear Aoyumi, could you please say some words about future integration aotuv into libvorbis 1.3.0.
What will be the base? Will be it beta 5.7 code or anything else?
There is not the matter that I can say about libvorbis 1.3.0 for the moment, sorry.
Hi Aoyumi,
If there is no problem with BS1, plz do a small stable (Edit: well I mean Beta) release before Monty swallows your code.
I don't use Vorbis for music actually but I still care for it if sites like wikipedia use xiph's codecs.
In all honesty I didn't test BS1 heavyly outside my listening test, but I recall it fixed a nasty bug without any noticeable regression. Even very small & specific the improvement on this particular bug was real.
It happens so rarely that Monty swallows aotuv that I don't want to wait 2 years for BS1 improvement to be merged
+1
Although BS1 did fix a major bug. The bitrate has increased a fair amount. Most things end up about 10-20kb higher than the target bitrate.
So I am not sure if it would be good to merge BS1 into libvorbis in its current state.
Bitrate is an issue indeed but I'd rather waste some space & make a step toward transparency than leaving bugs unfixed ... the problem is that if you target transparency & use ... say - q6 or above, then BS1 is a better choice than aotuv 5.7 ... if you don't care for transparency & use something below - q5 then the BS1 fixe doesn't matter because at mid-low bitrates vorbis has other problems that prevent it from being transparent anyway. It's a matter of choice, do you want real transparency or cheap overall efficiency with bugs. In other words BS1 is not really great for streaming, but if you're an audiophile making CD backup then it is necessary to fix as much bugs as possible IMHO. It must be the reason why I don't really use Vorbis anymore ...
If there is no problem with BS1, plz do a small stable (Edit: well I mean Beta) release before Monty swallows your code.
I don't use Vorbis for music actually but I still care for it if sites like wikipedia use xiph's codecs.
In all honesty I didn't test BS1 heavyly outside my listening test, but I recall it fixed a nasty bug without any noticeable regression. Even very small & specific the improvement on this particular bug was real.
It happens so rarely that Monty swallows aotuv that I don't want to wait 2 years for BS1 improvement to be merged
I can't yet include bs1 in beta release for test lack.
However, I will open the source code immediately if somebody needs it.
Although BS1 did fix a major bug. The bitrate has increased a fair amount. Most things end up about 10-20kb higher than the target bitrate.
So I am not sure if it would be good to merge BS1 into libvorbis in its current state.
It is not a bug. The bit rates increase if necessary. And the quantity depends on sources really.
Ah!. I can help you with joy, but my ears are not too for music)
I am not an authority as Guruboolez, though my asus xonar and koss portaPro are good for something)
I decided to ABX test five tracks at q4 encoded with beta5.7 and BS1 encoder. Are any recommendations for samples?
BS1 is a fix for the Rush sample from this ABX test (http://www.hydrogenaudio.org/forums/index.php?showtopic=70442&hl=multi+listening) ... I doubt you can ABX any difference (positive or negative) on any other problem sample. Good luck anyway.
I just have One request, Could somebody compile both BS1 and 5.7 in 64bit for some basic testing?
No special optimizations needed just whatever the compiler has built in, Lame saw a 25% perf boost just from being compiled in x64, I would like to see if there would be any perf boost for vorbis from 64bit
Oh and Aoyumi, Thank you very much for your hard work, I am a long time vorbis supporter and my last 2 portable players have been bought spicificly for their vorbis support, Your work on Vorbis has kept it at the top of my short list for lossy codecs(along with musepack).
I would just really like to at least beable to do some testing on x64 native code(dont worry, im an old skool beta tester, so bugs wont upset me at all)
Thanks again.
P.S. I have 5 other people lined up willing/excited to test an x64 compile of oggenc
Thank you for responses.
What is careful for the beta release exhibition that I incorporated BS1 in is because a other problem may spread by the change.
Then I showed (http://www.geocities.jp/aoyoume/aotuv/test) the BS1 patch some time ago.
Anyone can use it with a under license same as the aoTuV.
[semi-OT]: does anyone heard about this project (http://code.google.com/p/om-codec/) ?
Om is a from-scratch implementation of the Vorbis I audio compression specification. It does not use any code from the existing xiph.org libvorbis or libtremor implementation.
Primary goals
- Improve sandboxing of memory allocation.
- Improve performance on low-end (embedded/portable) platforms.
- Use only fixed-point operations, with no perceptible cost to quality.
- Be more maintainable than libvorbis, being written in a more modern, C++ style.
- Be as fast as existing implementations both on desktop and portables.
Future goals
- Fixed-point encoder, suitable for real-time usage on embedded/mobile platforms.
- Play around with alternative encoder algorithms.
Also in this project
- A from-scratch implementation of the FLAC lossless audio compression specification. This has a placeholder name "specflac", and implements only the decoder, for now.
...we can ask him to implement a different BS algorithm, don't you ?
[semi-OT] Does anyone heard about this "alternative Vorbis" implementation (http://code.google.com/p/om-codec/) ? (that seems active (http://code.google.com/p/om-codec/updates/list))
Om is a from-scratch implementation of the Vorbis I audio compression specification. It does not use any code from the existing xiph.org libvorbis or libtremor implementation.
Primary goals
- Improve sandboxing of memory allocation.
- Improve performance on low-end (embedded/portable) platforms.
- Use only fixed-point operations, with no perceptible cost to quality.
- Be more maintainable than libvorbis, being written in a more modern, C++ style.
- Be as fast as existing implementations both on desktop and portables.
Future goals
- Fixed-point encoder, suitable for real-time usage on embedded/mobile platforms.
- Play around with alternative encoder algorithms.
Also in this project
- A from-scratch implementation of the FLAC lossless audio compression specification. This has a placeholder name "specflac", and implements only the decoder, for now.
...just mailed him.
[semi-OT] Does anyone heard about this "alternative Vorbis" implementation (http://code.google.com/p/om-codec/) ? (that seems active (http://code.google.com/p/om-codec/updates/list))
Om is a from-scratch implementation of the Vorbis I audio compression specification. It does not use any code from the existing xiph.org libvorbis or libtremor implementation.
Primary goals
- Improve sandboxing of memory allocation.
- Improve performance on low-end (embedded/portable) platforms.
- Use only fixed-point operations, with no perceptible cost to quality.
- Be more maintainable than libvorbis, being written in a more modern, C++ style.
- Be as fast as existing implementations both on desktop and portables.
Future goals
- Fixed-point encoder, suitable for real-time usage on embedded/mobile platforms.
- Play around with alternative encoder algorithms.
Also in this project
- A from-scratch implementation of the FLAC lossless audio compression specification. This has a placeholder name "specflac", and implements only the decoder, for now.
...just mailed him.
Hi Guys
I was wondering if is the time for us to know more about future integration aotuv into libvorbis 1.3.0.
and if has anybody compile both BS1 and 5.7 in 64bit for some basic testing as AshenTech requested it? (just curious about the results)
Are there any plans about a new release of AoTuv's codec?
presenting new features or bug fixes?
Are there any plans about a new release of AoTuv's codec?
presenting new features or bug fixes?
aoTuV post-beta5.7 [20090914] (preview) released
aoTuV [20090914]
This is a test version including an important change of a plan included in in a next version.
download: http://www.geocities.jp/aoyoume/aotuv/test.html (http://www.geocities.jp/aoyoume/aotuv/test.html)
Cool... I just wonder what was the change (specific)... where it is at currently so far suits me... but if it improves... why not... I know I won't regret such a cool codec...
The other project from the "alternate vorbis" implementation, looks pretty interesting.
Besides (q-2) 32kbps sounds decent on generally the "rap" genre... "Example of music that isn't very complex..."
aoTuV post-beta5.7 [20091012] (preview) released
aoTuV [20091012]
This is a test version including an important change of a plan included in in a next version.
[Aoyumi] <aoyumi@gmail.com>
download: http://www.geocities.jp/aoyoume/aotuv/test.html (http://www.geocities.jp/aoyoume/aotuv/test.html)
I would very much like to know what this "important change of plan" is!
It's great to see Vorbis still being worked on, particularly aoTuV!
I would very much like to know what this "important change of plan" is!
It's great to see Vorbis still being worked on, particularly aoTuV!
you can read this(Japanese, auto translated to English by excite.co.jp(BizLingo))
http://excite.co.jp/world/english/web/?wb_...EN&wb_dis=2 (http://excite.co.jp/world/english/web/?wb_url=http%3A%2F%2Fwww2.atword.jp%2Faooa%2F&wb_lp=JAEN&wb_dis=2)
Does it say something bad about my ears that I can encode with this down to q-1.0 and still have it be transparent?
Indeed your lucky. I find it too noisy below Q3-4.
Ah, you're right. It is pretty noisy on very busy tracks, but for ~80% of the samples I've tested it on it ends up completely transparent. Note that I haven't trained myself to hear such things as pre-echo artifacts, but if they exist they certainly aren't obvious enough for an untrained ear to pick up.
Hi there vorbis fans
Aoyumi seems little quiet lately, does anyone of you has any news about the upcoming release?
With news or without It looks like vorbis is dead anyway. At least in regard of actively improvement the quality of the codec.
AoTuV is too mature to be "actively improved" IMHO.
The best measure of the maturity degree is tests like these (http://www.hydrogenaudio.org/forums/index.php?showtopic=70442) ;-)
Hi there vorbis fans smile.gif
Aoyumi seems little quiet lately, does anyone of you has any news about the upcoming release?
Everything in the AoTuV tunings will be merged into the main line source for the next major release of libvorbis 1.3.0. That's about it. On top of that an HA forum member compiled an SSE Optimized version of AoTuV tunings and created a 32-bit x86 Linux compile that's about 3x faster then the standard build.
The best measure of the maturity degree is tests like these ;-)
This test does not appear to be a very good indication of anything? This "added noise" everyone talks about is called "Noise Normalization". It's trivial for the lower quality values. It's not used beyond a -q 6. I am not of the impression that one should just keep tuning the encoder consistently as it may cause regressions especially if everything is not double checked and implemented in the mainline after further testing. I am not stating that AoTuV tunings are not very good, because they are. I am just stating there is possibility that might happen with some samples sometimes.
Hi there vorbis fans smile.gif
Aoyumi seems little quiet lately, does anyone of you has any news about the upcoming release?
Everything in the AoTuV tunings will be merged into the main line source for the next major release of libvorbis 1.3.0. That's about it. On top of that an HA forum member compiled an SSE Optimized version of AoTuV tunings and created a 32-bit x86 Linux compile that's about 3x faster then the standard build.
Any idea when libvorbis 1.3.0 will be released?
Any idea when libvorbis 1.3.0 will be released?
It depends on what projects Xiph is working on and what coincides with their schedule. I would think Monty would be the only one merging the tunings into the main branch, but he is still busy working on Theora. Unless the job is left up to someone else now or another contributor I am really not sure. I wouldn't put a time stamp on anything though!
aoTuV post-beta5.7 [20100314] (wip) released
*Probably "wip" mean "Work In Progress".
This is a test version including an important change of a plan included in in a next version.
[ Limit Quality -2/-1/0 ]
With fixed bug of "-ignore_length" in venc.
And, don't use less or equal -q-1 on 32kHz, libvorbis is buggy
download: http://www.geocities.jp/aoyoume/aotuv/test.html (http://www.geocities.jp/aoyoume/aotuv/test.html)
Great ! Very happy to see progress however slight!!
Can't wait until this is properly released with source code and all.
Any idea when libvorbis 1.3.0 will be released?
It depends on what projects Xiph is working on and what coincides with their schedule. I would think Monty would be the only one merging the tunings into the main branch, but he is still busy working on Theora. Unless the job is left up to someone else now or another contributor I am really not sure. I wouldn't put a time stamp on anything though!
For various reasons, a number of bug fixes and coupled surround support bumped their way way to the head of the line ahead of the AoTuV merge work. I'm pointing this out here just so no one will think that the work isn't happening— it just hasn't happened yet.
Xiph's and aotuv's work is always appreciated, and is always good to hear positive news about aotuv's .ogg project
I hope that day won't be far away
We all looking forward for the next release
New version of aoTuV released. Click (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=79762&view=findpost&p=705624)
Download from here (http://www.geocities.jp/aoyoume/aotuv/test.html).
Woot! 5.1 aotuv!
EDIT: Is anyone else getting problems trying to encode at any quality setting above q0? It just defaults to q0, no matter what you tell it to do!
EDIT2: Apparently it's already been answered (http://www.hydrogenaudio.org/forums/index.php?showtopic=79795). I have to say I find this ridiculous!
will wait for john33
How do you know Xanikseo that it just defaults to q0?
Is it mentioned anywhere?
lets hold on and wait to see what other guys would say
From
aoTuV 20100516.txt[ Limit Quality -2/-1/0/1 ]
If you try to encode with some other quality, it defaults to 0.
From aoTuV 20100516.txt
[ Limit Quality -2/-1/0/1 ]
If you try to encode with some other quality, it defaults to 0.
Hmmm guess we need to wait longer for the proper version then
from Monty blog, aoTuv is getting merge to the Vorbis main trunk soon
also the new WebM announcement from Google is a really good news to Vorbis, maybe more hardware player will support it now , things are getting excited again
wow my last visit was: Jan 16 2008, 12:47, it has been awhile, kinda quiet in the audio front lately.
give us links
you got any links to the websites you are refering to so we can read also?
give us links
you got any links to the websites you are refering to so we can read also?
I would call that anything but »soon«:
http://xiphmont.livejournal.com/50683.html...=138235#t138235 (http://xiphmont.livejournal.com/50683.html?thread=138235#t138235)
aoTuV post-beta5.7 [20100711] (for tester)
Limit Quality -2/-1/0/1/2
http://www.geocities.jp/aoyoume/aotuv/test.html (http://www.geocities.jp/aoyoume/aotuv/test.html)
Good good keep the updates coming, I'm looking forward to a full release with source code and all . I see slowly more q values are being accepted, now we're up to q2. Hopefully it won't take too long to accept all values of q up to 10...
I ABX tested this latest test build against the killer samples found at the following thread started by sauvage78:
Multi-Codec Listening Tests (http://www.hydrogenaudio.org/forums/index.php?showtopic=70442)
At q2 I could still easily ABX the Autechre, Abfahrt and Kraftwerk samples. Especially Autechre I could ABX at every try.
Cranberries___zombie_partial2 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=29717&view=findpost&p=256856) is also easy at -q2.
aoTuV post-beta5.7 [20100718] (for tester)
aoTuV [20100718] (r510) [ Limit Quality -2/-1/0/1/2 ]
I ABX tested this latest test build against the killer samples found at the following thread started by sauvage78:
Multi-Codec Listening Tests (http://www.hydrogenaudio.org/forums/index.php?showtopic=70442)
At q2 I could still easily ABX the Autechre, Abfahrt and Kraftwerk samples. Especially Autechre I could ABX at every try.
Unfortunately I do not make those samples a target this time.
Therefore, I may not anticipate the so big improvement with those samples.
Cranberries___zombie_partial2 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=29717&view=findpost&p=256856) is also easy at -q2.
In comparison with the former (beta) version, how?
You please tell me about it if you feel that it is bad than before.
aoTuV post-beta5.7 [20100718] (for tester)
aoTuV [20100718] (r510) [ Limit Quality -2/-1/0/1/2 ]
This is a bugfix version of "20100711".
The new problem by the specific pattern in the previous version was fixed.
just want to say thanks to Aoyumi for all your hard work and report a bug in your(and almost every other ogg encoder I have found) with LONG audio file conversion.
on files 6+hours long the encoder just errors out (not sure where the cut off is, 3hrs is fine, 6 errors), the only vorbis encoder I have found that dosnt have this issue no matter the file length/size is Spoon's encoder (dbpoweramp).
to explain I listen to alot of audio books, And size for quality I prefer vorbis to mp3, I just happened to run into this bug A while back and hope somebody can address the issue so i dont have to use spoons SLOW encoder despite its great quality its just SLOW.
just want to say thanks to Aoyumi for all your hard work and report a bug in your(and almost every other ogg encoder I have found) with LONG audio file conversion.
on files 6+hours long the encoder just errors out (not sure where the cut off is, 3hrs is fine, 6 errors), the only vorbis encoder I have found that dosnt have this issue no matter the file length/size is Spoon's encoder (dbpoweramp).
The encoding is possible via standard input in the current VENC.
I don't know about other encoders. Sorry.
Aoyumi, is your patch available somewhere so I can patch my libvorbis 1.3.1 in Linux with it?
Aoyumi, is your patch available somewhere so I can patch my libvorbis 1.3.1 in Linux with it?
There is not the patch for the moment.
If you use Wine on Linux, you can use the test version.
Aoyumi, is your patch available somewhere so I can patch my libvorbis 1.3.1 in Linux with it?
There is not the patch for the moment.
If you use Wine on Linux, you can use the test version.
libvorbis is used by other software I use: Native Linux software. Wine doesn't help. Wine only runs Windows programs.
Anyway, it would be nice if you could post your patch, not just the binary. Please don't forget that you are required (I think) to do this in the first place because of the libvorbis license terms.
Anyway, it would be nice if you could post your patch, not just the binary. Please don't forget that you are required to do this in the first place because of the libvorbis license terms.
libvorbis has BSD-style license.
libvorbis - Copyright © 2002-2008 Xiph.org Foundation
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
- Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
- Neither the name of the Xiph.org Foundation nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
That's all.
libvorbis is used by other software I use: Native Linux software. Wine doesn't help. Wine only runs Windows programs.
That it is used by various programs was not assumed.
I am concerned about a test copy being used in a wide range.
Anyway, it would be nice if you could post your patch, not just the binary. Please don't forget that you are required (I think) to do this in the first place because of the libvorbis license terms.
I respect software with developers.
Therefore I think that the license issue should be read carefully.
By the way, did you confirm a license terms?
[>> lvqcl]
Thank you for quotation.
I wasn't sure about the license. I assumed Vorbis was open source, which means we need to have the source. At least I'm sure it was open source in the past at some point. But I guess other people know this stuff better than me.
Anyway, it's sad that you don't provide the patch for this That way you only support Windows users and windows programs, which I don't use. Why not provide the patch? You provide the binary, so why not the patch? It would help many people. I'm still stuck to libvorbis 1.2.1, which has been dropped by my Linux distribution because it has security issues, and also it makes using some new versions of various programs impossible because they only work with new versions of libvorbis.
Please, consider providing a patch so that we can use new libvorbis + aotuv.
I wasn't sure about the license. I assumed Vorbis was open source, which means we need to have the source. At least I'm sure it was open source in the past at some point. But I guess other people know this stuff better than me.
Anyway, it's sad that you don't provide the patch for this That way you only support Windows users and windows programs, which I don't use. Why not provide the patch? You provide the binary, so why not the patch? It would help many people. I'm still stuck to libvorbis 1.2.1, which has been dropped by my Linux distribution because it has security issues, and also it makes using some new versions of various programs impossible because they only work with new versions of libvorbis.
Please, consider providing a patch so that we can use new libvorbis + aotuv.
If you have observed the history of Aoyumi's work, you should know that he always tests in this way and then once he is satisfied with his tuning efforts, full source is provided. The testing currently tasking place should probably be regarded as alpha testing of the incremental tuning that's taking place. Please be patient, you'll have access to the source once this next version is released. It's not usual to release source while testing is taking place.
BTW, 'open source' is a loose term that doesn't begin to define the terms of the licence under which it may be made available.
I love people who are rude(sorry but the attitude Nikaki puts forth is quite rude in my opinion) and expect to get what they demand.
I see this more in "open source" situations then in any others, I dont know why it is other then the fact that many FOSS people feel entitled to get what they want when they want it.....
I want to thank you again for your hard work Aoyumi, You are the one person who is actually trying to improve vorbis, and I for one respect that, dont let Hikaki's attitude bother you, and keep up the excellent work!!
so why not the patch?
Preparations are necessary to open it. It takes far time than I show test build. For example, the source cord overflows with personal memo, and it is necessary for it to rewrite it beforehand.
Of course the work is not only it.
It is very likely that I don't show the test binary at present if there was the premise to open the source cord.
@AshenTech
I'm not rude. I only wanted to use this with non-Windows operating systems. One has to be pretty emo to be offended by anything I said, since it was not rude by any stretch of the imagination.
@Aoyumi
We don't need the source code because we want to look at it We only need it so we can compile it. It doesn't matter if the source is pretty or not.
We don't need the source code because we want to look at it We only need it so we can compile it. It doesn't matter if the source is pretty or not.
Well, you wont get the source code, no matter how much you whine, because test version is only for testing (and there are enough testers on windows), not for people using it. You need to develop some patience, until Aoyumi considers the new aotuv ready you can always use the previous version.
@AshenTech
I'm not rude. I only wanted to use this with non-Windows operating systems. One has to be pretty emo to be offended by anything I said, since it was not rude by any stretch of the imagination.
Actually, I interpreted it as rude. A polite request and the graciousness to accept the answer you don't want would be open-minded.
So... (resume topic) I am always enthusiastic about cutting-edge tunings of Vorbis in the low bitrate range, I am rather fond of the results of -q-2 as an alternative for my radio show online archive to the more obscure Speex format (not knocking Speex, it just Vorbis has the advantage of having more supported players).
just a quick note, the sansa clip/clip+ and fuze all now have rockbox so speex is OK on its support by affordable players, but you are correct vorbis would be more supported.
I personally find q-0 to be the best choice for audio books and radio shows as when the audio gets more complex it scales up, but normally it keeps the bitrate very close to what speex gives me at its top quality settings.
q--2 (-2) can sound horrible on some headphones due to artifacts(dont really think anybody has optimized the - numbers to much even for voice)
and Im glad Im not the only one who saw his comments/attitude as rude, it came off as very demanding, as if hes entitled to get what he wants when he wants it........reminds me of my buddies teen age daughter who lived with her mother for a few years, spoiled little brat......
@Aoyumi:
Hello, I found that vorbis 1.3.1 for q4 or more has better stereo separation (or stereo fidelity) than the aotuv b5.7.
I look in the source of 1.3.1 and they put a lot of rewrite code in psy.c
please consider take attention in stereo sound stage and intensity of the music in your tunnings, they do a very good job in the harshness of some songs IMHO
sorry i sound rude, my inglish is poor
thanks
We don't need the source code because we want to look at it We only need it so we can compile it. It doesn't matter if the source is pretty or not.
Well, you wont get the source code, no matter how much you whine
Now you're the one being rude, accusing me of whining.
you can always use the previous version.
Well, that's the problem. I can't. It's been blacklisted for security reasons (that older libvorbis version has security bugs). I know that Windows doesn't care about stuff like this, but other OSes do.
Enough with the open source, Windows vs *nix yawnathon. Any further posts on the subject will be permanently deleted, and users will receive a TOS #5 warning.
We don't need the source code because we want to look at it We only need it so we can compile it. It doesn't matter if the source is pretty or not.
It is the same thing for me.
I can understand your thought, but cannot go along.
Hello, I found that vorbis 1.3.1 for q4 or more has better stereo separation (or stereo fidelity) than the aotuv b5.7.
I look in the source of 1.3.1 and they put a lot of rewrite code in psy.c
please consider take attention in stereo sound stage and intensity of the music in your tunnings, they do a very good job in the harshness of some songs IMHO
I can say nothing as far as there is not the sample.
But the stereo processing is changed with the existing test version.
I can say nothing as far as there is not the sample.
But the stereo processing is changed with the existing test version.
I test venc,exe version aoTuV post-beta5.7 [20100718] at -q2
with de aotuv b5.7 the song Wild Wild West of will smith, and in the chorus at the 2nd voice that have a high pitch i hear a little loss of power and stereo, is like a loss of high frecuency fault like blur or something.
but with de testing version post b5.7(above) i can't hear a big difference, in fact i hear differences (i guess for the quality level) but the energy of the music is almost the same
b5.7 = 99kbps (q2)
testing= 107 kbps (q2)
K:\>venc -q2 www.wav www.ogg
aoTuV Post Beta 5.7 - OggVorbis Encoder (c) 2003-2010 Aoyumi
Output file : "www.ogg"
Stream info.: 2ch/44.1kHz/16bit(int) -> 2ch/44.1kHz/32bit(float)
Quality 2 (nominal bitrate : 96kbps)
Processing...Done.
[Report of the encoded file]
play time : 245.533 sec.
encode time : 11.692 sec. (x21.000)
stream bitrate : 107.34 kbps
bit reduction : 1 / 13.1
i think tha is most visible the stereo at high quality (q4 or q5) when the music is more detailed and at this level of q i cant hear (q2) any artifacts but i hear the loss of power or wide stereo image or blur or roughness .
in conclusion, i'm waiting the new aotuv version based in the code of stereo procesing of 1.3 series
thanks mr. aoyumi
PD: i hear the difference in the stereo in the songs with 360º stereo sound like the chorus of "s club 7- friday night" but others with flat stereo i can't hear nothing
AlexDDR,
It will be helpful if you will upload up to 30 seconds (allowed limit) of mentioned sample somewhere. It could be Upload section (http://www.hydrogenaudio.org/forums/index.php?showforum=35) or somewhere else like rapidshare.
The words has a little meaning without sample.
Also, read the rules (http://www.hydrogenaudio.org/forums/index.php?showtopic=3974). Especially N8.
AlexDDR,
It will be helpful if you will upload up to 30 seconds (allowed limit) of mentioned sample somewhere. It could be Upload section (http://www.hydrogenaudio.org/forums/index.php?showforum=35) or somewhere else like rapidshare.
The words has a little meaning without sample.
Also, read the rules (http://www.hydrogenaudio.org/forums/index.php?showtopic=3974). Especially N8.
Sorry my mistake for not having posted results of ABX to confirm my findings, until then I beg you not to take into account my long post until I have the ABX support we'll see how it goes with foobar and ABX.
thakns for the warning, I was a little disoriented
I released the new test version (http://www.geocities.jp/aoyoume/aotuv/test). (for tester)
CHANGES (from post-beta5.7 [20100718])
* The one of the issue of noise to rarely occur at the low bit rate (eg -q-2) was improved.
* New dynamic stereo processing is added.
If you found the problem that is peculiar to this version, please inform me.
I released the new test version (http://www.geocities.jp/aoyoume/aotuv/test). (for tester)
CHANGES (from post-beta5.7 [20100718])
* The one of the issue of noise to rarely occur at the low bit rate (eg -q-2) was improved.
* New dynamic stereo processing is added.
If you found the problem that is peculiar to this version, please inform me.
Any feedback on this build it's been a month without any reply or bugs found.
Keep up the good work Aoyumi, I've been following your progress for few years.
Thank you for your great work!!!
Hello,
I'm looking forward to the next version.
Thank's for your excellent work, Aoyumi.
Best regards
akapuma
I noticed that some problems were left in the shown latest test version now a few days ago. (fixed now)
New beta version will be released after fine tuning and code rearranging without a problem besides it.
::
Thank you so much for this!
::
When we can expect new Beta? It's been a long time since last release.
Btw.
aoTuV is the best thing that happened to Vorbis.
The very best thing
Hi Aoyumi!
Excuse me for the curiosity, but what are the news? I wait impatiently for the release!
aoTuV makes me happy.
(http://i240.photobucket.com/albums/ff137/rimnuggets/Signature.jpg)
Oh! Guys! I saw Aotuv last visited hydrogenaudio at Sep 20 2010. I am afraid Aotuv project is dropped
Maybe it's as good as it can get? Maybe this is Heaven?
Hello all of you.
I continue developing "aoTuV".
It cannot be said that the development is active, but the release of the new version seems to be possible soon.
Please wait for a while...
Aoyumi
Heck, that's good news^^
Looking forward to it.
Regards, Clobon
A new release would be great, a release with the superior sound quality of the aotuv-builds, merged with the advantages of the dynamic stereo processing / channel coupling of the official builds.
Best regards
akapuma
I released new beta6.
Enjoy
Aoyumi
::
Thank you very much! You made my day.
Greetings ...
::
John, it is your turn!
John, it is your turn!
I'm on it!
+1
Bug report: incorrect encode of short_block_test_2.flac
(you can download it here - http://web.archive.org/web/20030618115117/...s/test_samples/ (http://web.archive.org/web/20030618115117/http://www.hydrogenaudio.org/extra/samples/test_samples/) )
added: here it is [attachment=6375:short_block_test_2.wv]
Thanks Aoyumi.
A big thank you goes out to you Aoyumi! I will test it thoroughly. Regards.
A full set of compiles is available at Rarewares as of now.
Bug report: incorrect encode of short_block_test_2.flac
(you can download it here - http://web.archive.org/web/20030618115117/...s/test_samples/ (http://web.archive.org/web/20030618115117/http://www.hydrogenaudio.org/extra/samples/test_samples/) )
The File is not accessible, at least for me.
P.S. Time for a listening test. Who is courageous) ?
P.P.S. Thank you John!
I attached short_block_test_2 to my post.
Problem with short_block_test_2 confirmed. It's easily audible.
It's interesting to notice how lossy codecs struggle on this sample while lossless compresses it to 5 kbps.
oggenc2.87-aoTuVb6-generic -q4 Vs Lossless
foo_abx 1.3.4 report
foobar2000 v1.1.2
2011/02/22 22:23:47
File A: C:\Users\Blah\Desktop\ashort_block_test_2.ogg
File B: C:\Users\Blah\Desktop\short_block_test_2.wv
22:23:47 : Test started.
22:24:22 : 01/01 50.0%
22:24:46 : 02/02 25.0%
22:25:08 : 03/03 12.5%
22:25:33 : 04/04 6.3%
22:25:55 : 05/05 3.1%
22:26:26 : 06/06 1.6%
22:27:04 : 07/07 0.8%
22:28:07 : 08/08 0.4%
22:28:09 : Test finished.
----------
Total: 8/8 (0.4%)
Bzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz, it's not transparent from the start, the above ABX log is only made using the 5 first seconds.
The bug itself is not at the beginning but at the end of file at second 10-13, it's like a water noise. Very easyly ABXable. (My ABX log doesn't reflect the bug itself, the bug is huge no need to ABX)
sounds like this:
Bzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz (not transparent) + bug at second 10
Edit1:
I tested because I was waiting after the new version for my own listening test, I dunno what to do now, should I wait ? (I don't care personnaly, in fact I was even expecting the release next week)
Edit2:
Just tested AO; aoTuV b5d [20090301] -q4, I dunno if it's transparent or not as I didn't bother ABXing, but the water noise/bug is not present at second 10-13.
You needed four minutes for 8 positive ABX in a "Very easily noticeable" test? :?
What's wrong, you methodology to test, or your description?
Sorry, don't get your problem. I knew which artefact I was searching & I always found it, so for me it was easy.
As I said the bug is not included in the ABXing. Obviously you didn't read correctly.
Edit: In case it wasn't clear I will re-word it: I ABXed the 5 first seconds only (which is not transparent) & the bug itself is at second 10-13 so not ABXed (but it doesn't need ABXing anyway as it is huge)
Yeah, I heard it, sounds like water jug artifact that should not be there.
Odd, at -q0 it doesn't f*** up at all that I can hear.
edit: forgot to mention was using Rarewares generic compile, if it matters.
edit2: artifact bug reported starts happening at -q2 and above
Hi there,
first things first: a very big Thank you to Aoyumi and John33 for all the good work!!!
Is there a chance that this bug concerning short_block_test_2 will be audible in "normal" music?
Regards, Clobon
Bug report: incorrect encode of short_block_test_2.flac
(you can download it here - http://web.archive.org/web/20030618115117/...s/test_samples/ (http://web.archive.org/web/20030618115117/http://www.hydrogenaudio.org/extra/samples/test_samples/) )
added: here it is [attachment=6375:short_block_test_2.wv]
Thank you for a report.
I investigated it and found one mistake.
I will release the revision soon.
Aoyumi
Thank you for a report.
I investigated it and found one mistake.
I will release the revision soon.
Aoyumi
I'm glad that it helped. And thanks for the new aoTuV.
@Aoyumi
At first Aoyumi, thank you very match for your work again !!!!!
On topic: I have idea, It is not new and maybe a little bit premature but I propose to release final beta6 branch (e.g. beta 6.4 ... you know) as Aotuv Release2 (R2) with the purpose to reflect stability and fine changes from Release 1
aoTuV Beta6.01 [beta6 >> beta6.01] (2011/02/23)
# In the specific pattern, the bug that caused overflow was fixed.
John, it is your turn!
I'm on it!
John! Please repeat
Hi all,
I released (http://www.geocities.jp/aoyoume/aotuv/) a revision.
Please replace the previous version with the new version.
Aoyumi
John, it is your turn!
I'm on it!
John! Please repeat
OK, give a few minutes.
6.01 complies now available.
Is it Oggenc 2.85 using aoTuVb 6.01 or Oggenc 2.87 using aoTuVb 6.01? Just wondering because of the version listed on the Rarewares.org page before I 7-Zip them up and archive them locally.
Link: http://www.rarewares.org/ogg-oggenc.php#oggenc-aotuv (http://www.rarewares.org/ogg-oggenc.php#oggenc-aotuv)
C:\>oggenc2.exe -h
OggEnc v2.87 (aoTuV Beta 6.01)
© 2000-2005 Michael Smith <msmith@xiph.org>
& portions by John Edwards <john.edwards33@ntlworld.com>
Usage: oggenc2 [options] input.wav [...]
Is it Oggenc 2.85 using aoTuVb 6.01 or Oggenc 2.87 using aoTuVb 6.01? Just wondering because of the version listed on the Rarewares.org page before I 7-Zip them up and archive them locally.
Link: http://www.rarewares.org/ogg-oggenc.php#oggenc-aotuv (http://www.rarewares.org/ogg-oggenc.php#oggenc-aotuv)
Sorry, I'll change that to 2.87.
Edit: Done.
Thank you, Aoyumi.
Really great work.
Congratulations and thank you very much
I used many trial issues since August of the last year without knowing this one.
(http://img43.imagevenue.com/loc38/th_23340_01_122_38lo.jpg) (http://img43.imagevenue.com/img.php?image=th_23340_01_122_38lo.jpg)
what is the recommended preset for the current version
thank you all
I'm having trouble with john33's oggenc2 and encoding of 6 ch WAV file: bitrate is too low (average 151 kbps @ Q10), sounds awfully. Previous version (based on b5.7) encodes file properly.
Can confirm the bug with venc.exe too. Vanilla vorbis 1.3.2 is ok.
Looks like bug in aotuv but not in John compilation.
@john33
Could you change your oggenc2's writing library in OGG COMMENT?
oggenc2(yours)
AO; aoTuV [20110223] (based on Xiph.Org's libVorbis)
venc
AO; aoTuV [20110223] (based on Xiph.Org's libVorbis)
I wanna diplay your oggenc2 for aotuv
like this
(http://img272.imagevenue.com/loc366/th_25183_01_122_366lo.jpg) (http://img272.imagevenue.com/img.php?image=th_25183_01_122_366lo.jpg)
It's called "vendor string", both looks identical in your post, so what's your problem? john33 ain't gonna display oggenc2 version in vorbis's vendor string if that's what you're asking for. (I'm not sure I get what you want ...)
it's called "vendor string", both looks identical in your post.
OH
Sorry,I didnt care here is not for Foobar.
But I hope he understand what im saying
Very interesting things, at my laptop all is ok (with venc and oggenc2) with converting 6ch-wav to 6ch-ogg, but the 6ch samples are different. Maybe the problem is file specific.
I will additionally check the problem at home today night and attach a problematic sample if so.
@john33
Could you change your oggenc2's writing library in OGG COMMENT?
oggenc2(yours)
AO; aoTuV [20110223] (based on Xiph.Org's libVorbis)
venc
AO; aoTuV [20110223] (based on Xiph.Org's libVorbis)
I wanna diplay your oggenc2 for aotuv
like this
(http://img272.imagevenue.com/loc366/th_25183_01_122_366lo.jpg) (http://img272.imagevenue.com/img.php?image=th_25183_01_122_366lo.jpg)
Are you saying that you want the 'AO: ' removed from the front of the Vendor String? If so, I'm not sure that I should considering Aoyumi created the modified libraries and that is his chosen Vendor String. To change it might suggest that I am using a different version of the libraries.
Just tried to encode a 5.1 file (6 channels in F2K) [Dances With Wolves Speech Sample (DTS Master) 48Khz], -q4 I get 331Kbps (128x5/2=320Kbps expected) & quality seems ok (Didn't ABX)
So personnaly I cannot reproduce the bug (Doesn't mean there isn't any).
Edit:
I used john33's oggenc2 like capma, not venc like alter4.
I don't know if the BS (Block-Switching) issue has been addressed in this latest Beta v601 release, but I can still easily ABX the Autechre killer sample.
The fact that such a bad sample for vorbis is still easyly ABXable is not really a surprise IMHO (unless you expect miracles like aotuv b2 at each aotuv release), the real question is more: is there any improvement even if still ABXable.
@john33
Could you change your oggenc2's writing library in OGG COMMENT?
oggenc2(yours)
AO; aoTuV [20110223] (based on Xiph.Org's libVorbis)
venc
AO; aoTuV [20110223] (based on Xiph.Org's libVorbis)
I wanna diplay your oggenc2 for aotuv
like this
(http://img272.imagevenue.com/loc366/th_25183_01_122_366lo.jpg) (http://img272.imagevenue.com/img.php?image=th_25183_01_122_366lo.jpg)
Are you saying that you want the 'AO: ' removed from the front of the Vendor String? If so, I'm not sure that I should considering Aoyumi created the modified libraries and that is his chosen Vendor String. To change it might suggest that I am using a different version of the libraries.
I wish to read from OGG COMMENT as TAG in writing library by Encoder at (or)Foobar
Im not talking bout BSD or ect
Well.i gave up it
Thanks jonn33
@sauvage78
Yes you're right this new release is definately better. I ABXed the following samples and could only ABX Autechre:
01- DCT Killer Samples (Lossless)\01- Artefact+Context\01- Abfahrt Hinwil (Artefact+Context) Lossless.flac
01- DCT Killer Samples (Lossless)\01- Artefact+Context\02- Autechre (Artefact+Context) Lossless.flac
01- DCT Killer Samples (Lossless)\01- Artefact+Context\03- Castanets (Artefact+Context) Lossless.flac
01- DCT Killer Samples (Lossless)\01- Artefact+Context\04- Harlem (Artefact+Context) Lossless.flac
01- DCT Killer Samples (Lossless)\01- Artefact+Context\05- Kraftwerk (Artefact+Context) Lossless.flac
01- DCT Killer Samples (Lossless)\01- Artefact+Context\06- Rush (Artefact+Context) Lossless.flac
01___Pet_Shop_Boys___In_The_Night___cutted.flac
bibilolo.flac
emese.flac
Linchpin__Edit_.flac
Replica._Lossy.flac
So thanks Aoyumi for the splendid work.
@OggY68
Did the bitrate increase a lot for these samples (compared to previous aoTuV) ?
@OggY68
Did the bitrate increase a lot for these samples (compared to previous aoTuV) ?
I only tested them at default -q3 quallity setting.
Other killer samples for vorbis are badvilbel and the_product.
Hi ALL.
I am Back with 6ch encoding problems. The problem is sample(or maybe format) specific.
There is a one of problematic 6ch file.
Download sample (http://depositfiles.com/files/sm3tkwsgh) and try to encode using aotuv beta6.01 to catch the bug.
Thx and hope somebody helps to fix.
P.S. HA! looks I find the problem! aotuv can't properly encode 44100 rate 6ch files, but can 48000 rate! Please confirm!
Confirmed. Resampled file (to 48000) encodes correctly.
It is clear now. The question is closed, new bug report is open.
P.S. But the good news are 32000hz 6ch files convert properly as well, so I think it something like "slip of the pen" in aotuv code, and Aoyumi (if hi has free time and good opportunity ) can easily fix it.
aoTuV Beta6.02 [beta6.01 >> beta6.02] (2011/02/27)
# In the specific pattern (different from beta6.01), the bug that caused overflow was fixed.
New aotuv version is out, but the bug with 6ch files is still there.
C:\unknown>venc.exe -q4 6ch.wav
aoTuV Beta 6.02 - OggVorbis Encoder © 2003-2011 Aoyumi
Output file : "6ch.ogg"
Stream info.: 6ch/44.1kHz/16bit(int) -> 6ch/44.1kHz/32bit(float)
Quality 4 (nominal bitrate : 324kbps)
Processing...Done.
[Report of the encoded file]
play time : 17.842 sec.
encode time : 1.968 sec. (x9.066)
stream bitrate : 94.08 kbps
bit reduction : 1 / 45
Thx for your work Aoyumi.
About 5.1ch
I recognize the problem.
There are some causes, and time is necessary in investigation and a revision.
Sorry.
Aoyumi
aoTuVb6.02 compiles are now at Rarewares.
About 5.1ch
I recognize the problem.
There are some causes, and time is necessary in investigation and a revision.
Sorry.
Aoyumi
OK. I think this bug is not critical, not all guys rip 6ch music from movies to ogg:)
But just for sure Aoyumi could I ask you? Will you profile fix ...as ready... or postpone the fix for a long term?
Sorry again if you feel me tactless.
About 5.1ch
I recognize the problem.
There are some causes, and time is necessary in investigation and a revision.
Sorry.
Aoyumi
OK. I think this bug is not critical, not all guys rip 6ch music from movies to ogg:)
But just for sure Aoyumi could I ask you? Will you profile fix ...as ready... or postpone the fix for a long term?
Sorry again if you feel me tactless.
I want to release fixed version in the time early as possible.
But I cannot yet declare it about the time...
I dont rip in 6ch but have been a big fan of youre work Aoyumi cant wait to try the new version out.
Thank you very much Aoyumi!
lead_voice (http://www.hydrogenaudio.org/forums/index.php?showtopic=50056) sample:
1 - original
2 - encoded with aotuv b6.02 -q4
3 - resampled to 88kHz and encoded
4 - resampled to 96kHz and encoded
(http://img849.imageshack.us/img849/1885/lead064.png)
1 - original
2 - encoded with aotuv b6.02 -q4
3 - resampled to 88kHz and encoded
4 - resampled to 96kHz and encoded
Hello lvqcl,
thank you for your tests.
I think, number 2 is OK, and number 3 is not OK.
What is with number 4? Is it OK? There is some schlieren between the lines.
I think, the original is 44,1kHz. Have you tested 48kHz, too? This is the common sample rate for digital TV (DVB).
Best regards
akapuma
I cannot see or hear problems with this sample resampled to 48kHz.
What is with number 4? Is it OK?
Numbers 3 and 4 aren't not OK IMHO (ABXed 8/8).
lead_voice (http://www.hydrogenaudio.org/forums/index.php?showtopic=50056) sample:
1 - original
2 - encoded with aotuv b6.02 -q4
3 - resampled to 88kHz and encoded
4 - resampled to 96kHz and encoded
Thank you for a report.
If the problem that you recognize produces even "libvorbis 1.3.2", I understand the problem.
I intend to try the improvement of the problem in the future.
Aoyumi
If the problem that you recognize produces even "libvorbis 1.3.2", I understand the problem.
I intend to try the improvement of the problem in the future.
Oops. Sorry that I didn't this before. Yes, libvorbis 1.3.2 also shows similar problems with 88 and 96kHz, but in other places of the track.
Hello Aoyumi,
is everything OK with you? In your user profile is written, that you are living in Kanto. And I saw, that Kanto is near Fukushima.
My best wishes to you, to your family and the whole Japanese nation.
Best regards
akapuma
These types of messages should be done via PM, please read TOS #5 if you have any questions.
That said, my heart goes out to all those affected and to be affected by the catastrophe in Japan.
These types of messages should be done via PM, please read TOS #5 if you have any questions.
That said, my heart goes out to all those affected and to be affected by the catastrophe in Japan.
ok true but i don't find anything wrong showing your sympathy to an individual
Especially when he's the man singlehandedly responsible for keepin' Vorby competitive with constant updates.
He's not been on since the last post: Last Seen: 7th March 2011 - 06:48
He updated his blog (in Japanese) today.
That's very good to hear. Thanks, Nao.
I wonder how the 3 main competitors (WMA Pro, HE-AAC and Vorbis) fare in the 64-96 kbps range these days.
Hi all.
We shook by an earthquake greatly in the hometown, but I and my relative are safe now.
I intend to release the revision of aoTuV soon.
Good to know! Thanks for all of your hard work.
Is good to hear from you again Aoyumi
Keep up
We are all with you!!!
Glad you and you're loved ones are ok.
Thanks for you're dedication in improving vorbis.
Hi Aoyumi.
Glad to hear good news from you! Could you answer please, I want to encode quit big amount of 2ch WAVs. Is an upcoming version has any quality improvements for 2ch music? In other words are any reasons to wait new revision?
Hi Aoyumi.
Glad to hear good news from you! Could you answer please, I want to encode quit big amount of 2ch WAVs. Is an upcoming version has any quality improvements for 2ch music? In other words are any reasons to wait new revision?
Planned "aoTuV" to release soon is the revision of 5.1 channel coupling. It isn't different in encoding of 2ch music.
Aoyumi,
Thx for the clarification.
-----------------------------------------------------------------
Three Mile Island - 79, Chernobyl - 86, fukushima - 2011. As a citizen of Belarus, the most polluted country in 1986
I have the right to ask, Are the nuclear plants safe?
I released (http://www.geocities.jp/aoyoume/aotuv/) a fix version of "aoTuV".
It can normally process 5.1ch sources.
Then, the encoding result of 2ch sources doesn't change.
Enjoy
Aoyumi
Hello Aoyumi,
thank you very much for this!
What means "latest beta version" in red, bold and italic letters?
"The newest" version? Or that the next version will be a final (non-beta) version? Or that there are no new versions intended in the future?
best regards
akapuma
Thx for aotuv beta 6.03
I have a Question for Aoyumi
It's possible to improve further encoding efficient at all bit rates (-q-2 to -q10)?
1. Similar CABAC, RDO coding with exhaustive model search for higher compression ratio or better audio quality at the same bit rate (-q0)
- Better sharp transient handling especially at all bit rates (32 – 512kbp/s)
- Remove low pass filter at -q10
- Improve monophonic quality
2. Add 24bit wav source for encode true 24bit ogg files (for audiophile listener)
3. Clipping detection
4. Add EBU R128 Loudness scanner (to end the loudness war)
thx for hard work!!
sorry for my poor english
2. Add 24bit wav source for encode true 24bit ogg files (for audiophile listener)
Wait for Rarewares' build of OggEnc2, it allows 24b input.
"True 24b Vorbis" is something really odd, though. Sound material loses its bit depth upon being encoded by Vorbis (not unlike vector images), and using a lossy codec on such high quality content would also be kind of... defeating its purpose, I guess.
EBU R128 scanner is also something that would be an OggEnc feature, not a part of the actual codec.
Pardon my ignorance, but how CABAC lossless compression can be applied to Vorbis which uses Huffman compression? ("The entropy coding in a Vorbis I codebook is provided by a standard Huffman binary tree representation", link (http://xiph.org/vorbis/doc/Vorbis_I_spec.html))
Also, even at -q7 oggenc doesn't apply lowpass filter.
And, whad does "Clipping detection" means?
What means "latest beta version" in red, bold and italic letters?
"The newest" version? Or that the next version will be a final (non-beta) version? Or that there are no new versions intended in the future?
It means "The newest" version"
- Better sharp transient handling especially at all bit rates (32 – 512kbp/s)
- Improve monophonic quality
Yes, you are right.
- Remove low pass filter at -q10
Even other versions are similar.
Or that the next version will be a final (non-beta) version?
Makes me wonder when Release 2 will ever be.
Where I can get oggenc binary?
TodaY I have some free time to play...
P.S. Or please provide me information how to build it. I am Java developer. I think I am capable to compile C code after some exercises
http://lmgtfy.com/?q=aoyumi+vorbis (http://lmgtfy.com/?q=aoyumi+vorbis)
http://lmgtfy.com/?q=aoyumi+vorbis (http://lmgtfy.com/?q=aoyumi+vorbis)
Ha! I did it without lack. Sorry I forgot to mention that I need windows binaries.
Compile it on linux platform is quite easy, but at present days I run windows platform.
Indeed I don't think compile it for windows is too complex, but for mitigating wasting of time tutorial is highly appreciable
Sorry I forgot to mention that I need windows binaries.
You can use "Win32 reference binary" from Aoyumi's web page.
That's venc not oggenc. You can usually get windows binaries from http://www.rarewares.org/ogg-oggenc.php (http://www.rarewares.org/ogg-oggenc.php), but the latest version there is b6.02, so that's not much help at the moment I'm afraid. john33 get to it !
John 33
are planning to do the compiles for the new version (aoTuVb6.03)?
http://lmgtfy.com/?q=aoyumi+vorbis (http://lmgtfy.com/?q=aoyumi+vorbis) -> http://www.geocities.jp/aoyoume/aotuv/ (http://www.geocities.jp/aoyoume/aotuv/) -> http://www.geocities.jp/aoyoume/aotuv/binary/aoTuV_b6.03.zip (http://www.geocities.jp/aoyoume/aotuv/binary/aoTuV_b6.03.zip)
Rename venc to oggenc.
Venc doesn't support adding vorbis tags!
I want exactly what I want.
Aoyumi:
I've noticed various Vorbis files that failed to decode in rockbox over the years due to lack of memory, and aside from a few very old files using floor0, nearly all were encoded with various aoTuV versions. Is there some way to predict how much memory various aoTuV encodes will use? Or at least someway for a user to know that a given file won't require an excessive amount of memory for a portable device?
I realize the vorbis spec does not put a limit on how much memory a file can use, but many MP3 players have only so much RAM on the device.
I've noticed various Vorbis files that failed to decode in rockbox over the years due to lack of memory, and aside from a few very old files using floor0, nearly all were encoded with various aoTuV versions.
That's odd... The only Vorbis files I've seen that Rockbox failed to decode and weren't using floor0, failed due to really large comments packets (i.e., big album art). I haven't used any low memory target though, if that makes any difference.
Aoyumi:
I've noticed various Vorbis files that failed to decode in rockbox over the years due to lack of memory, and aside from a few very old files using floor0, nearly all were encoded with various aoTuV versions. Is there some way to predict how much memory various aoTuV encodes will use? Or at least someway for a user to know that a given file won't require an excessive amount of memory for a portable device?
I realize the vorbis spec does not put a limit on how much memory a file can use, but many MP3 players have only so much RAM on the device.
The memory consumption of "aoTuV" cannot have a wide margin than "Xiph.Org's libvorbis".
I never did the change that influenced memory consumption greatly.
Generally quantity to use depends on setup header size.
I've noticed various Vorbis files that failed to decode in rockbox over the years due to lack of memory, and aside from a few very old files using floor0, nearly all were encoded with various aoTuV versions.
That's odd... The only Vorbis files I've seen that Rockbox failed to decode and weren't using floor0, failed due to really large comments packets (i.e., big album art). I haven't used any low memory target though, if that makes any difference.
The size of ogg page and/or comment header seems to surely become the problem.
At first decoder should scan header part.
The memory consumption of "aoTuV" cannot have a wide margin than "Xiph.Org's libvorbis".
I never did the change that influenced memory consumption greatly.
Generally quantity to use depends on setup header size.
Edit: Yeah, looks like this one had a huge album art image in the header I missed. Still i'm surprised this allocates memory in rockbox. I gutted a lot of the metadata code in tremor a while ago, didn't realize album art was still being parsed.
Edit: Yeah, looks like this one had a huge album art image in the header I missed. Still i'm surprised this allocates memory in rockbox. I gutted a lot of the metadata code in tremor a while ago, didn't realize album art was still being parsed.
It isn't parsed, but the packet is still buffered by the Ogg layer.
I need your help guys
I usually download the generic compile from john33 i unrar the file, i open dbpoweramp locate the oggenc2.exe and convert in .ogg with dbpoweramp converter, I did the same with the new version and i got the error: "error writing audio data to StdIn pipe"
Does anyone can help me with this?
Hi,
I see a big difference in average bitrate going from quality 6.9999 to 7. That does not happen with Xiph's libvorbis.
Is this happening because a certain filter/setting changes by default at quality 7? Or is it a bug somewhere?
I am not sure 100% but suppose at q7 new values of impulse_noisetune impulse_trigger_profile are applied. As result - bit rate bloat.
Hi,
I see a big difference in average bitrate going from quality 6.9999 to 7. That does not happen with Xiph's libvorbis.
Is this happening because a certain filter/setting changes by default at quality 7? Or is it a bug somewhere?
I've seen something that happen between 3.9 and 4.0 where the noise shaping crossover is (actually, the reverse. 3.9 is slightly more bitrate intensive than 4.0). I didn't see it at 5.9 to 6.0 though, where the joint stereo crossover (well, the vorbis equivalent) is. not sure what may be going on between 6.9 and 7.0. Maybe the aggressive quality tuning gives out past the q6 range?
Nezmer.
Hum... I suppose you specified q as -q6,99999 but not -q6.99999
because 6.999999 = 6 for encoder
P.S. Anyway if do it right the difference in bitrate is 15kbps in my case
Nezmer.
Hum... I suppose you specified q as -q6,99999 but not -q6.99999
because 6.999999 = 6 for encoder
P.S. Anyway if do it right the difference in bitrate is 15kbps in my case
6.9999 as -aq (ffmpeg) and -q(oggenc).
15kbps is about right with (average) files.
It goes from 245.3 to 272.6 with El Carretero(track 8 from Buena Vista Social Club). A bitrate-hungry track, It seems.
C:\1>oggenc2.exe -q6.9999999 Alouette.wav -o 699.ogg
Opening with wav module: WAV file reader
Encoding "Alouette.wav" to
"699.ogg"
at quality 6,00
[ 99,9%] [ 0m00s remaining] \
Done encoding file "699.ogg"
File length: 1m 25,0s
Elapsed time: 0m 03,0s
Rate: 28,5863
Average bitrate: 181,8 kb/s
C:\1>ogginfo.exe -v 699.ogg
Processing file "699.ogg"...
New logical stream (#1, serial: 00001215): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: AO; aoTuV [20110424] (based on Xiph.Org's libVorbis)
Channels: 2
Rate: 44100
Nominal bitrate: 192,000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
Total data length: 1949210 bytes
Playback length: 1m:25.758s
Average bitrate: 181,831599 kb/s
Logical stream 1 ended
C:\1>oggenc2.exe -q6,9999999 Alouette.wav -o 699.ogg
Opening with wav module: WAV file reader
Encoding "Alouette.wav" to
"699.ogg"
at quality 7,00
[ 99,6%] [ 0m00s remaining] |
Done encoding file "699.ogg"
File length: 1m 25,0s
Elapsed time: 0m 02,0s
Rate: 42,8795
Average bitrate: 221,5 kb/s
C:\1>ogginfo.exe -v 699.ogg
Processing file "699.ogg"...
New logical stream (#1, serial: 000003ed): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: AO; aoTuV [20110424] (based on Xiph.Org's libVorbis)
Channels: 2
Rate: 44100
Nominal bitrate: 224,000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
Total data length: 2374406 bytes
Playback length: 1m:25.758s
Average bitrate: 221,495908 kb/s
Logical stream 1 ended
C:\1>
Do you see?
C:\1>oggenc2.exe -q6.9999999 Alouette.wav -o 699.ogg
Opening with wav module: WAV file reader
Encoding "Alouette.wav" to
"699.ogg"
at quality 6,00
[ 99,9%] [ 0m00s remaining] \
Done encoding file "699.ogg"
File length: 1m 25,0s
Elapsed time: 0m 03,0s
Rate: 28,5863
Average bitrate: 181,8 kb/s
C:\1>ogginfo.exe -v 699.ogg
Processing file "699.ogg"...
New logical stream (#1, serial: 00001215): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: AO; aoTuV [20110424] (based on Xiph.Org's libVorbis)
Channels: 2
Rate: 44100
Nominal bitrate: 192,000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
Total data length: 1949210 bytes
Playback length: 1m:25.758s
Average bitrate: 181,831599 kb/s
Logical stream 1 ended
C:\1>oggenc2.exe -q6,9999999 Alouette.wav -o 699.ogg
Opening with wav module: WAV file reader
Encoding "Alouette.wav" to
"699.ogg"
at quality 7,00
[ 99,6%] [ 0m00s remaining] |
Done encoding file "699.ogg"
File length: 1m 25,0s
Elapsed time: 0m 02,0s
Rate: 42,8795
Average bitrate: 221,5 kb/s
C:\1>ogginfo.exe -v 699.ogg
Processing file "699.ogg"...
New logical stream (#1, serial: 000003ed): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: AO; aoTuV [20110424] (based on Xiph.Org's libVorbis)
Channels: 2
Rate: 44100
Nominal bitrate: 224,000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
Total data length: 2374406 bytes
Playback length: 1m:25.758s
Average bitrate: 221,495908 kb/s
Logical stream 1 ended
C:\1>
Do you see?
Never used oggenc2.
Float values are accepted in the tools I use (As far as I know).
ffmpeg rounds to 7 with 6.9999999. oggenc with 6.999999.
Ok
The purpose is to show 6.999999 = 6 for oggenc encoder
The difference in 15 kbps I got with q value 6,999 for oggenc
The separator depends on the system locale, so for some languages 6.999 is correct and for other languages you have to use 6,999.
Hi,
I see a big difference in average bitrate going from quality 6.9999 to 7. That does not happen with Xiph's libvorbis.
Is this happening because a certain filter/setting changes by default at quality 7? Or is it a bug somewhere?
Some parameters are not interpolated in libvorbis. And they increase than libvorbis 1.3.2 in "aoTuV beta6.03".
It is a cause of a big difference of bitrate.
These are not bugs.
Hi,
I see a big difference in average bitrate going from quality 6.9999 to 7. That does not happen with Xiph's libvorbis.
Is this happening because a certain filter/setting changes by default at quality 7? Or is it a bug somewhere?
Some parameters are not interpolated in libvorbis. And they increase than libvorbis 1.3.2 in "aoTuV beta6.03".
It is a cause of a big difference of bitrate.
These are not bugs.
Thank you for your answer.
The separator depends on the system locale, so for some languages 6.999 is correct and for other languages you have to use 6,999.
Oh! Shame on me! It is quite obvious.
I need your help guys
I usually download the generic compile from john33 i unrar the file, i open dbpoweramp locate the oggenc2.exe and convert in .ogg with dbpoweramp converter, I did the same with the new version and i got the error: "error writing audio data to StdIn pipe"
Does anyone can help me with this?
anyone who understands to help me?
Open command prompt window and try to encode .wav file using oggenc2 directly.
There is a hard sample for beta 6
link (http://www.hydrogenaudio.org/forums/index.php?showtopic=88515)
Hi everyone, one question. I'm encoding with the new version of Aotuve and the previous version, at setting -q4.
With the new version the size from a ripped CD is from 5 to 10 mb greater.
Why is that ?? It means the new aoutuve is better or maybe, the new q4 is now q3 ??
Greetings from Peru
SergioMC
It means the new version decides to allocate more bits to preserve a certain level of quality. Theoretically this level of quality should be somewhat higher than what the previous version output at -q4, and probably higher than what the previous version output at the same bitrate values.
How many hours of audio material have you tested so far? 2-3 in the same style, or 20-30 in different styles? You need as much data as possible for representative statistics.
I have a question: Will aoTuV ever hit "Release 2" status?
Aoyumi or anyone else who knows, what are the significant differences between libvorbis 1.3.2 and AoTuV b6.03?
Please read what s new from beta 3 to beta 6 (aotuv beta2 ~ libvorbis 1.3.2 in terms of quality)
http://www.geocities.jp/aoyoume/aotuv/ (http://www.geocities.jp/aoyoume/aotuv/)
What about technical changes and differences in it - I don't mind.
Please read what s new from beta 3 to beta 6 (aotuv beta2 ~ libvorbis 1.3.2 in terms of quality)
http://www.geocities.jp/aoyoume/aotuv/ (http://www.geocities.jp/aoyoume/aotuv/)
Hm, I'm confused. I've seen that page, but I thought Aoyumi's tweaks have been moved into libvorbis much more recently than beta 3?
Edit: If I read things correctly, aotuv was merged into libvorbis 1.3.2 at b5.7 or b6. Not sure which.
Here is an interesting blind test of 5.7 and 6.0 from one Japanese guy/woman
http://d.hatena.ne.jp/kamedo2/20110409/1302373616 (http://d.hatena.ne.jp/kamedo2/20110409/1302373616)
was wondering if anybody whos skilled at compiling would be interested/willing to give this compiler a go(its free)
http://developer.amd.com/tools/open64/Page...t.aspx#whatsnew (http://developer.amd.com/tools/open64/Pages/default.aspx#whatsnew)
apparently its x86-32 and x86-64 paths for amd chips are better on both intel and amd then gcc's or ms's (from what i have been reading).
would be interesting to see results of something other then MS/Intel compilers at least
Would be interesting indeed, possibly something more agnostic than *cough* other compiler(s). Would be willing to try compiles with my old Athlon64.
Here's a shortcut to the current download page: http://www.open64.net/download/open64-4x-releases.html (http://www.open64.net/download/open64-4x-releases.html)
http://developer.amd.com/tools/open64/Page...fault.aspx#four (http://developer.amd.com/tools/open64/Pages/default.aspx#four)
also can get it there.
I don't think it's the same...isn't it a different branch?
Hello
Is it possible to make a couple of additional settings oggenc.
I am interested in the integration settings of mpcenc - 1.30
parameters:
== Masking thresholds ======
- quality x set Quality to x
- nmt x set NMT value to x dB
- tmn x set TMN value to x dB
- pns x set PNS value to x dB
I have two question, guys)
The first one to the Aoyumi. What is your plans for the future aotuv version? Could you please clarify?
And the second one to everyone. Is there anybody here informed about libvorbis 1.4.0 development?
Hello
Is it possible to make a couple of additional settings oggenc.
I am interested in the integration settings of mpcenc - 1.30
parameters:
There is not the plan of such an expansion for the moment.
I don't feel the need of the function very much...
I have two question, guys)
The first one to the Aoyumi. What is your plans for the future aotuv version? Could you please clarify?
There is the plan. It is not yet the stage that I can announce.
Hi Aoyumi,
There is new libvorbis release at http://downloads.xiph.org/releases/vorbis/ (http://downloads.xiph.org/releases/vorbis/) ,
for now I'm feeling forced t switch to it, as newest aoutv is based on older
releases and there were some security fixes. Nonetheless, thanks for superb
work
From the change log of libvorbis 1.3.3:
additional proofing against invalid/malicious streams in decode
Since aotuv is used for encoding, it should still be safe to use it.
There is not the plan of such an expansion for the moment.
I don't feel the need of the function very much...
Agree.
It would be great to have a different downmix to mono procedure (not just L+R).
Stereo Tool's image manipulator-like (http://help.stereotool.com/stereo_image_manipulator.shtml) algorithm would be great, IMHO.
From the change log of libvorbis 1.3.3:
additional proofing against invalid/malicious streams in decode
Since aotuv is used for encoding, it should still be safe to use it.
I'm not sure that is true. Safe to use for encoding, yes, but it probably would be a good idea to apply the patch that fixes the 1.3.2 decode bug to the aoTuV source if you have decoding software that end up using the decoding library provided by aoTuV. If using a binary based on aoTuV for encoding only then probably safe.
I will see if I can find the specific patch because I'm now using aoTuV on my systems having replaced the patched vendor library, thus more than likely re-introducing the vulnerability on my systems.
From the change log of libvorbis 1.3.3:
additional proofing against invalid/malicious streams in decode
Since aotuv is used for encoding, it should still be safe to use it.
I'm not sure that is true. Safe to use for encoding, yes, but it probably would be a good idea to apply the patch that fixes the 1.3.2 decode bug to the aoTuV source if you have decoding software that end up using the decoding library provided by aoTuV. If using a binary based on aoTuV for encoding only then probably safe.
I will see if I can find the specific patch because I'm now using aoTuV on my systems having replaced the patched vendor library, thus more than likely re-introducing the vulnerability on my systems.
So this is the change between 1.3.2 and 1.3.3:
https://trac.xiph.org/changeset?new=18186%4...%2Fvorbis%2Flib (https://trac.xiph.org/changeset?new=18186%40trunk%2Fvorbis%2Flib&old=17584%40trunk%2Fvorbis%2Flib)
Here is a diff that applies most of them :
http://yum.domblogger.net/dblog/aotuv-b6.0..._1.3.3.diff.txt (http://yum.domblogger.net/dblog/aotuv-b6.03_1.3.2_1.3.3.diff.txt)
It does NOT patch the lib/psy.c file as aoTuV is different there from upstream libvorbis.
I don't think that's where the security issue was anyway.
It also does NOT patch the GENERAL_VENDOR_STRING or ENCODE_VENDOR_STRING - leaves former at 1.3.2 and latter at what aoTuV set it to.
Everything else is applied.
An rpm spec file that builds in RHEL/CentOS 6.x :
http://yum.domblogger.net/dblog/aotuv.spec (http://yum.domblogger.net/dblog/aotuv.spec)
Can someone explain why "oggenc2.exe -q 2.5 test.wav" produces the same result as "oggenc2.exe -q 2.0 test.wav"? In Help it is said "Fractional qualities (e.g. 2.72) are permitted". And foobar2000 also allows to encode into q2.5.
Use decimal comma:
oggenc2.exe -q 2,5 test.wav
Use decimal comma
Thank you. This is strange that they did it this nonstandart way...
Use decimal comma
Thank you. This is strange that they did it this nonstandart way...
Comma as decimal separator is actually ISO standard (ISO 31). In fact, it was the
only permitted decimal separator under the standard until 2003, when one also decided to permit the point on the line (but not the mid dot of pre-typewriter English).
(Not that I ever cared ... for maths, I would use the full stop whenever I had to make a list (comma-separated), and comma whenever I needed to use the mid dot as multiplication sign.)
Aren't there some applications which carelessly uses the computer locale to pick numbers, and hence screw up big time in scripting?
The german locale uses the comma as decimal separator.
But PCs and their software were founded in Silicon Valley in USA, where the english-based decimal points are usual, so it became the default when ignoring locales.
I wonder if Aoyumi have lost interest in developing of his fork... Last time we have seen him was in 2011.
In any case, he made a tremendous contribution and would like to thank him once more.
I'm waiting for full acknowledgement of importance of his work by inclusion of his latest code in mainline vorbis.
I wonder if Aoyumi have lost interest in developing of his fork... Last time we have seen him was in 2011. :(
I would like to see aoyumi try his hand at tuning opus!
In any case, he made a tremendous contribution and would like to thank him once more.
Amen to that... aoyumi's work has been magnificent. We have to remember that he has developed aotuv for many years unpaid in his own time as a labour of love and if he now needs or wishes to concentrate his time upon other commitments we must surely understand this and be grateful for what he has done that has given pleasure to many of us around the world.
I'm waiting for full acknowledgement of importance of his work by inclusion of his latest code in mainline vorbis.
This is where I am curious and would be grateful if someone could clarify. My understanding was that the then current aotuv was merged into libvorbis 1.1 in 2004 and that since, although further aotuv merges were on the to do list, Monty was too busy working on other things to be able to do the merges. However, the release notes to libvorbis 1.3.2 state:
vorbisenc: Back out an [old] AoTuV HF weighting that was
first enabled in 1.3.0; there are a few samples where I
really don't like the effect it causes.
So from that it sounds as though aotuv tunings have been getting merged into libvorbis after all (albeit selectively)?
I realise that listening tests have provided strong evidence that aotuv is superior to libvorbis, but the listening tests in question all seem to be from many years ago.
Assuming that aotuv tunings have been getting merged into libvorbis in the succeeding years, as the quote above suggests, would the assertion that aotuv is considerably better than libvorbis still be valid?
Has libvorbis caught up?
Finally, my understanding is that aotuv is tuned predominantly for low bitrates.
As storage space on mobile devices continues to increase, I find myself able to transcode my flac files to vorbis at higher bitrates than I used to.
If I were to encode at a higher bitrate (I am thinking of q 6) would I still be better off using aotuv or would I be better off using libvorbis?
What would folks recommend?
This is where I am curious and would be grateful if someone could clarify.
libvorbis SVN r18889 (or r18951, for that matter) does
not have aoTuV b6.03. I am in possession of the relevant unified diff of the two trees.
Finally, my understanding is that aotuv is tuned predominantly for low bitrates.
this is true, but tuning lower quality settings (if I understand correctly) changes higher quality settings also.
hi aoyumi, what exactly was changed in beta 6.03 (2014) when it's not sound quality part?
hi aoyumi, what exactly was changed in beta 6.03 (2014) when it's not sound quality part?
I could be wrong, but I think it's just a merge with libvorbis 1.3.4.
I could be wrong, but I think it's just a merge with libvorbis 1.3.4.
Exactly:
aoTuV Beta6.03 (2014) (2014/5/11)
# The latest aoTuV beta6.03 was unified with Xiph.Org's libvorbis1.3.4. The part related to sound quality is not changed from previous version.
is there any posibility to see any new update of Aoyumi's version of codec again? or is an abandoned project.
Is there any new update from anyone anyway?
I still use ogg vorbis and i was interested if there is still an action from anyone.
The latest aotuv is based on 1.3.5 ver of libvorbis, so it's up to date I guess.
but isnt an old version too? Is been some time to hear an update
Just look at the official vorbis site. libvorbis 1.3.5 is the newest release.
Most of the optimizing efforts probably goes towards opus now anyway.
I think that Nicos asks about psychoacoustic model development.
aoTuV Beta6 was developed 5 years ago, and there were no changes since then.
aoTuV Beta6.03 (2018) (2018/5/2) was released
# The latest aoTuV beta6.03 was unified with Xiph.Org's libvorbis1.3.6. The part related to sound quality is not changed from previous version.
http://www.geocities.jp/aoyoume/aotuv/binary/aoTuV_b6.03_2018.7z (http://www.geocities.jp/aoyoume/aotuv/binary/aoTuV_b6.03_2018.7z)
The obvious question is here if nowadays' Vorbis has yet whatever to offer over AAC and Opus (xcept wider support on HW players ofcourse tho even this is disputable)
On modes other than LC, AAC can be heavy on decoding side. On some portables and older phones can show various issues. I think vorbis, mpc, mp3 (not sure of optus) offer similar performance no matter what bitrate. This could be an advantage for vorbis - streaming audio at 64 k vs AAC HE resource wise while still offering OK quality. Otherwise like mpc, theres a reference free encoder for all bitrates . Opus I never tested. I have an older android phone and AAC 32..64k stream somtimes reduce battery drasticaly or get it running hot.
On modes other than LC, AAC can be heavy on decoding side. On some portables and older phones can show various issues. I think vorbis, mpc, mp3 (not sure of optus) offer similar performance no matter what bitrate. This could be an advantage for vorbis - streaming audio at 64 k vs AAC HE resource wise while still offering OK quality. Otherwise like mpc, theres a reference free encoder for all bitrates . Opus I never tested. I have an older android phone and AAC 32..64k stream somtimes reduce battery drasticaly or get it running hot.
From these results on the rockbox wiki, ACC-HE and AAC-HEv2 seem to require more cpu clocks to decode. On older processors it will drain the battery faster.
https://www.rockbox.org/wiki/CodecPerformanceComparison
https://www.rockbox.org/wiki/CodecPerformanceComparison#AMS_AS3525v2_w_47_24MHz_PCLK_40ARM926EJ_45S_41