Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: .Ogg Vorbis aotuv (Read 492015 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

.Ogg Vorbis aotuv

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

.Ogg Vorbis aotuv

Reply #251
Quote
Aoyumi, could you please explain what is about patch for version 5.61?

Yes. (But it needs some tests)
Quote
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.

.Ogg Vorbis aotuv

Reply #252
Thx!

.Ogg Vorbis aotuv

Reply #253
New source patch for vorbis decoder!

Translated with excite.co.jp
Code: [Select]
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

Download
http://www3.atwiki.jp/ao?cmd=upload&ac...ock_speedup.zip

@Aoyumi:
Can this patch apply to ARM processors(WinCE/WM)?
Sorry for my English.

.Ogg Vorbis aotuv

Reply #254
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.

.Ogg Vorbis aotuv

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

Quote
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.
budding I.T professional

.Ogg Vorbis aotuv

Reply #256
OK, I'll post ABX log and samples as soon as I have some time. It will however take some time, I'm afraid...

.Ogg Vorbis aotuv

Reply #257
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:

Code: [Select]
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!

.Ogg Vorbis aotuv

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

Quote
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.

.Ogg Vorbis aotuv

Reply #259
[/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).

.Ogg Vorbis aotuv

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



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.


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.
budding I.T professional

.Ogg Vorbis aotuv

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

Quote
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.

.Ogg Vorbis aotuv

Reply #262
[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. 

Quote


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 ;-)

.Ogg Vorbis aotuv

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

Its much easier for me to find patches that way.

.Ogg Vorbis aotuv

Reply #264
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.

Code: [Select]
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

Quote
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.

Quote
In the future, consider posting patches to our tracker:

http://www.rockbox.org/tracker/index.php?type=4

Its much easier for me to find patches that way.
Thank you for a suggestion. 


.Ogg Vorbis aotuv

Reply #266
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/

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.

.Ogg Vorbis aotuv

Reply #267
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":
Code: [Select]
/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
Code: [Select]
/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, -t "TRACKNUMBER=%n/%x" could be changed for -t "TRACKNUMBER=%n" -t "TOTALTRACKS=%x".
Code: [Select]
/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"
Code: [Select]
/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.

.Ogg Vorbis aotuv

Reply #268
"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!

.Ogg Vorbis aotuv

Reply #269
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.

.Ogg Vorbis aotuv

Reply #270
"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.

.Ogg Vorbis aotuv

Reply #271
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.

.Ogg Vorbis aotuv

Reply #272
"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

 

.Ogg Vorbis aotuv

Reply #273
A full set of aoTuVb5.7 compiles is now available at Rarewares.

.Ogg Vorbis aotuv

Reply #274
A full set of aoTuVb5.7 compiles is now available at Rarewares.

...and a big "thank you" for John33 and Aoyumi is available here!