Ogg Vorbis optimized for speed, ca. 1.5x faster than 1.1 original ver. Options

[vearutop]

thnx

something wrong was with my eyes... i visited that page earlier, but haven't seen subj

[vearutop]

strange thing...
i compressed track via standart aotuvb3 and w/ sse optimized one. then i decompressed them to waves. waves were not the same...

maybe this is not a very fair optimisation?

[rjamorim]

i compressed track via standart aotuvb3 and w/ sse optimized one. then i decompressed them to waves. waves were not the same...

maybe this is not a very fair optimisation?

Even when you use different compilers for the same source code you can get different vorbis streams. So, it's to be expected that assembly optimizations will introduce differences.

It's up to the users to test and see if these differences are noticeable.

[bluesky]

I used the build from this url.

Here's my results with an Athlon XP 3200+:

CODE

ArcherB10 oggenc:

       File length:  5m 05.0s
       Elapsed time: 0m 11.0s
       Rate:         27.7879
       Average bitrate: 161.5 kb/s

rarewares icl oggenc:
       File length:  5m 05.0s
       Elapsed time: 0m 20.0s
       Rate:         15.2833
       Average bitrate: 152.5 kb/s

I didn't notice other people getting different bitrates out of their tests. I did a simple:

CODE

oggenc -q5 testl.wav

Ideas?

This post has been edited by bluesky: Feb 6 2005, 03:08

[QuantumKnot]

Seems like a significant difference. Which specific ICL oggenc from rarewares did you use? There are a couple there.

[nyaochi]

Ideas?

The optimized binary (Archer Beta10) is based on aoTuV b3. Did you use aoTuV b3 binary at rarewares for comparison?

[bluesky]

My mistake... correct data:

CODE

Done encoding file "testl.ogg"

       File length:  5m 05.0s
       Elapsed time: 0m 12.0s
       Rate:         25.4722
       Average bitrate: 161.5 kb/s


Done encoding file "testl.ogg"

       File length:  5m 05.0s
       Elapsed time: 0m 20.0s
       Rate:         15.2833
       Average bitrate: 161.5 kb/s

[Toe]

Has any testing been done on these builds with regard to output quality? (ie no noticable differences vs regular 2.1)

[DarkAvenger]

BTW, GCC 4.0 alpha snapshot from yesterday compiles the SSE version fine.

BTW, encoding time for a test file went down form 5.5 to 3.0 seconds on my Athlon XP...
Hmm, but on the other hand a non-SSE version compiled with gcc-3.4 only needs 4.3 seconds... so GCC 4.0 still needs a lot of work before it is ready for prime time.

OK, it seems using more conservative flags is better for gcc 4.0: Using

CODE

CFLAGS="-O2 -fweb -frename-registers -mno-ieee-fp -D_REENTRANT -fsigned-char -march=athlon-xp -mfpmath=sse -fomit-frame-pointer"

gcc4.0 is about as fast as gcc 3.4.3 w/o SSE.

This post has been edited by DarkAvenger: Feb 21 2005, 13:07

[Emanuel]

Do I dare asking John33 for an english OggdropXPd SSE optimized version when the time is ready? Would be like a dream for an Iriver H140 owner

This post has been edited by Emanuel: Feb 21 2005, 14:04

[rjamorim]

Do I dare asking John33 for an english OggdropXPd SSE optimized version when the time is ready? Would be like a dream for an Iriver H140 owner

I wonder if it would be a good idea, considering we still didn't see any listening tests comparing the optimized version versus the official one.

[john33]

Do I dare asking John33 for an english OggdropXPd SSE optimized version when the time is ready? Would be like a dream for an Iriver H140 owner

I'm not averse to the idea. I simply haven't managed to get a clean compile to work with yet!! I keep taking another look, and I'll continue to do so, but until then, it's a 'no can do'!

[Emanuel]

I wonder if it would be a good idea, considering we still didn't see any listening tests comparing the optimized version versus the official one.

You're right. Although, with the short abx tests I did yesterday, I am very satisfied with the quality in the sse version vs aoTuV b3 and official 1.1 - so I would definetly use it. The speed gain compared to a possible difference between the versions (wich I couldn't abx) is reason enough EDIT: for me

I'm not averse to the idea. I simply haven't managed to get a clean compile to work with yet!!   I keep taking another look, and I'll continue to do so, but until then, it's a 'no can do'!

Fully understandable, John. You're already doing a great job.

This post has been edited by Emanuel: Feb 21 2005, 15:03

[Josef K.]

I'd be more interested in decoder speedups - especially for portable devices. Vorbis playback in my Tungsten T3 eats battery like crazy.

fefe was working on a (apparently buggy) SSE optimization of libvorbis too.
Do the optimizations only effect encoding or decoding as well?

Oh, I didn't know fefe's optimization. I'll check whether it benefits Blacksword's optimization.

IMHO this optimization effects on both encoding and decoding sides although optimized oggdec is not tested or released. Several functions for decodnig (e.g., vorbis_synthesis_blockin, mapping0_inverse, mdct_backward, etc.) are optimized too.

Hello,
I'm newb here, so please be patient

OK, my question is:
Can using these compiles (actually OggEnc_SSE_20041213ArcherB10) instead of "normal one" (I'm using aoTuV b3 - OggEnc Win32 version - from Aoyumi pages) speed up decoding of vorbis when played on portable player (iaudio M3 in my case) and cause lower energy consumption?
Increase of encoding speed isn't important for me, but if this will happend...

One offtopic subquestion : mp3 files plays almost gaplessly comparing to vorbis ones on my player (also when encoded with this SSE comp.) Is this because of slow decoding (with Tremor decoder?), is this a hardware issue (slow processor / vorbis requirements?) or is this a firmware issue (...)?

So maybe I'm totally off topic, maybe not? THX for your reactions.

[miscellanea]

OK, my question is:
Can using these compiles (actually OggEnc_SSE_20041213ArcherB10) instead of "normal one" (I'm using aoTuV b3 - OggEnc Win32 version - from Aoyumi pages) speed up decoding of vorbis when played on portable player (iaudio M3 in my case) and cause lower energy consumption?
Increase of encoding speed isn't important for me, but if this will happend...

encoding and decoding is diffrent process (diffrent engine) so I think decoding speed is a matter of player.

One offtopic subquestion  : mp3 files plays almost gaplessly comparing to vorbis ones on my player (also when encoded with this SSE comp.) Is this because of  slow decoding (with Tremor decoder?), is this a hardware issue (slow processor / vorbis requirements?) or is this a firmware issue (...)?

hmm, Tremor is vorbis decoder so it may be because of mp3 decoders.
Originally mp3 can't play gaplessly (some players are cutting gap when playing, so it's like gapless playing).

This post has been edited by miscellanea: Mar 12 2005, 11:42

[eloj]

Archer Release-Candidate 1 is out.

[miscellanea]

Thanks. Now is the time to test again.

[Josef K.]

Archer Release-Candidate 1 is out.

Accidentally I found very strange (rare) bug in Archer RC1:
With one sample (Laurie Anderson / Big Science / song no. 08 - Let X=X) the encoder fail, but only when -q4 is used. (e.g. -q4,1; -q3 -q5 etc. makes no problem)
Lenght of the song is 3:54, when encoding fail, it ends at 3:27 (whole song till this point is encoded and tags are properly added). Doesn't matter if the source for encoding is wav or flac. It happend with EAC as well as with Foobar:

CODE

INFO (foo_clienc) : CLI encoder: C:\Program Files\Eac\Encoders\Vorbis\OggEnc_SSE_20050312ArcherRC1\oggenc.exe
INFO (foo_clienc) : Destination file: file://C:\Documents and Settings\Martin Radimecky\My Documents\My Music\OGG\Rock\Anderson, Laurie\Big Science\08 - Let X=X.ogg
INFO (foo_clienc) : Source file: file://C:\Documents and Settings\Martin Radimecky\My Documents\My Music\FLAC\Rock\Anderson, Laurie\Big Science\08 - Let X=X.flac
INFO (foo_clienc) : 44100Hz 32bps 2ch
ERROR (foo_clienc) : Writing to encoder failed
INFO (foo_clienc) : Encoding took 10828 milliseconds, speed 19.24x
INFO (CORE) : attempting to edit file info : file://C:\Documents and Settings\Martin Radimecky\My Documents\My Music\OGG\Rock\Anderson, Laurie\Big Science\08 - Let X=X.ogg
INFO (CORE) : file info update successful on : file://C:\Documents and Settings\Martin Radimecky\My Documents\My Music\OGG\Rock\Anderson, Laurie\Big Science\08 - Let X=X.ogg
ERROR (foo_diskwriter) : Conversion failed.

Encoding does not fail when another compiles (e.g. oggenc2.41-aoTuVb3P3 from RW or Aoyumi reference compile) are used.

The strangest thing is, that only the full lenght wav must be used to cause the fail. I tried to isolate just part of the sample which causes the fail for uploading it here, but it encodes without problems. Even when small part is cut off from very beginning of the wav, it encodes well. But when the whole wav is resaved, the problem stays the same.

(the whole sample in flac is 20 Mb, so I can't upload it here)

Edit: oops, I forgot this: OggEnc_SSE_20041213ArcherB10 perform without problems on this sample !?!

Edit 2: Anyway, encoding speed is amazing

This post has been edited by Josef K.: Mar 12 2005, 21:15

[rutra80]

I also have a WAV which fails to encode with RC1 (doesn't dump any error message, just creates a dummy 0 bytes big OGG file) but with previous versions encodes just fine.

[Zoom]

I can confirm the bug here too:

CODE

Opening with wav module: WAV file reader
Encoding "Wilco - Spiders (Kidsmoke).wav" to
        "Wilco - Spiders (Kidsmoke).ogg"
at quality 4.00
       [ 52.3%] [ 0m08s remaining] \

The encoder cuts out at exactly that spot every time. The file is fine and playable even, however the encoder stops at that point. I would assume it is a sample problem, as the part of the song it fails in would probably pose a problem to the encoder. I'm not sure though. I did test the encoder on about 10 other files of varying length and genre. All of the other files encoded without fail.

I agree though, the speedup of this encoder over the standard ICL auTov encode is amazing on my A64 3500+ :

CODE

Opening with wav module: WAV file reader
Encoding "Death Cab for Cutie - Stability.wav" to
        "Death Cab for Cutie - Stability.ogg"
at quality 4.00
       [100.0%] [ 0m00s remaining] /

Done encoding file "Death Cab for Cutie - Stability.ogg"

       File length:  12m 21.0s
       Elapsed time: 0m 20.0s
       Rate:         37.0800
       Average bitrate: 116.6 kb/s

20 seconds for a twelve and half minute song, nice!

This post has been edited by Zoom: Mar 12 2005, 23:23

[Josef K.]

20 seconds for a twelve and half minute song, nice! 

Well, but it's not applicable (specially to batch encoding) with such unpredictable results as posted above

[eloj]

Archer RC2 is out.

[Josef K.]

Archer RC2 is out.

Regrettably, exactly the same problem (with the same sample) as RC1 detected here
(RC1 bug report can be found here)

[rjamorim]

Regrettably, exactly the same problem (with the same sample) as RC1 detected here
(RC1 bug report can be found here)

What's the point of posting the report at a forum the developer probably doesn't read?

If I were you I would send him an e-mail, and hope that he speaks at least some english.

[eloj]

If I were you I would send him an e-mail, and hope that he speaks at least some english.

I just sent him an email referencing this thread and that specific post. It would probably be helpful if someone could supply a test file.

Edit: I finally found a file that I have that crashes the encoder. It's track 14 off the Pain of Salvation - Be album. Let's see.. crash at around 65,3% completed....

Edit 2: Very tricky to pin down. This track only crashes at -q 3 of the different qualities I tried.

Edit 3: Okay, running under debugger:

"oggenc_archer.exe The instruction at 0x0042D568 referenced memory at 0xBF4EB730. The memory could not be read."

CODE

.text:0042D512 cvtss2si ecx, [eax+edi*4+0Ch]
.text:0042D518 cvtss2si ebx, [eax+edi*4+8]
.text:0042D51E cvtss2si esi, [eax+edi*4+4]
.text:0042D524 cvtss2si eax, [eax+edi*4]
.text:0042D529 mov     edi, [esp+50h+var_20]
.text:0042D52D add     ecx, edi
.text:0042D52F add     ebx, edi
.text:0042D531 add     esi, edi
.text:0042D533 add     edi, eax
.text:0042D535 mov     eax, [esp+50h+var_18]
.text:0042D539 imul    eax, [edx+8]
.text:0042D53D mov     [esp+50h+var_20], edi
.text:0042D541 mov     edi, [esp+50h+var_14]
.text:0042D545 add     eax, [edi+ecx*4]
.text:0042D548 imul    eax, [edx+8]
.text:0042D54C add     eax, [edi+ebx*4]
.text:0042D54F imul    eax, [edx+8]
.text:0042D553 add     eax, [edi+esi*4]
.text:0042D556 imul    eax, [edx+8]
.text:0042D55A mov     edx, [esp+50h+var_20]
.text:0042D55E add     eax, [edi+edx*4]
.text:0042D561 mov     edx, [esp+50h+var_10]
.text:0042D565 mov     edx, [edx+8]
.text:0042D568 cmp     dword ptr [edx+eax*4], 0          <--------------
.text:0042D56C jle     loc_42D6FE
.text:0042D572 mov     edx, [ebp+arg_C]
.text:0042D575 mov     ecx, [edx+10h]

It's a function that starts at 0x42D2FC and takes four parameters. Seems to only get called explicitly from one place, but its address is taken twice, so it could called as a function pointer too?. I'm not familiar enough with the code to identify it any further, and I don't think I even have the tools to build the source.

This post has been edited by eloj: Mar 18 2005, 17:32