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

[eloj]

Alright, the author got back to me. I'm going to assume he won't mind me posting his reply here:

"This BBS is seen.
This problem occurs in local_book_besterror_dim8.
I received the data which a problem occurs by RC1.
The data can be normally encoded by RC2.

The samples of the data which a problem occurs are insufficient. "

I'm going to try and figure out if he's got the bandwidth to recieve "samples" from us or not, though it doesn't seem _too_ hard to reproduce if you've got one or two whole albums to encode at different quality settings.

Edit: Some potentially good news:

"Probably, it will be unnecessary.
I found the clear problem in local_book_besterror_dimX. "

Looking forward to RC3.

Edit 2: Got to run a pre-release of RC3 where the bug seems to have been fixed --- at least my only test-case is working now. Furthermore, this does not seem to have impaired encoding speed at the least. (I do however detect a slight change in file size)

This post has been edited by eloj: Mar 18 2005, 22:08

[Josef K.]

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

My point was to warn other people against using the compile, because I think it's just fortuity to find this bug (in case of RC1 I encoded 8 albums without any problems before) and give evidence that RC2 does not solve the problem (it was easy for me check this because I know the "wrong" sample). Maybe I'm naive, but it's so catchy to use compile like this...

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

Of course you are right. I wasn't quick enough (as posted above)

[Josef K.]

Edit 2: Got to run a pre-release of RC3 where the bug seems to have been fixed --- at least my only test-case is working now. Furthermore, this does not seem to have impaired encoding speed at the least. (I do however detect a slight change in file size)

Here the problem seems to be fixed too (with Oggenc_rc3_pre01.exe on the same sample like before). I've sent email to blacksword about this result too.
I'm looking forward to RC3

[DreamTactix291]

Archer RC3 is out.

[eloj]

F:\wav\archer>oggenc_archer -v
OggEnc v1.1 (Archer RC1 based on AoTuV Beta03)

Still displaying the wrong version, but at least the files are tagged correctly. Odd that these are different strings.

[rutra80]

Well, bad news I think - my WAV still doesn't encode with RC3 (outputs a 0 bytes dummy OGG). What I noticed is that sampling rate of that WAV is 32KHz, I tried with another 32KHz file and it didn't encode either, so it looks like a problem with this certain sampling-rate. I also tried some 22KHz, 44KHz, and 48KHz files and they encode fine.

EDIT: I checked with -q-2 only.

This post has been edited by rutra80: Mar 19 2005, 13:33

[eloj]

I can confirm that 32KHz files don't work at all at negative quality settings:

CODE

.text:0041A53D mov     eax, [esp+60h+var_24]
.text:0041A541 mov     edi, [eax+esi*4]              ; <-------- crash at negative quality, 32KHz
.text:0041A544 movss   xmm1, dword ptr [ebx+edi*4]
.text:0041A549 mov     edx, [ebx+edi*4]
.text:0041A54C movss   xmm0, xmm1
.text:0041A550 mulss   xmm0, xmm0

Looks like the base register isn't set up correctly (eax).

Hopefully it's just a problem with the loader.

edit:

F:\wav\archer>oggenc_archer --resample 32000 -q -1 Posbe14.wav
Opening with wav module: WAV file reader
Resampling input from 44100 Hz to 32000 Hz
Encoding "Posbe14.wav" to "Posbe14.ogg" at quality -1,00
<crash>

No such luck.

Samplerates < 26000 and > 39999 == "works" (encoder doesn't crash).

Edit 2:

"Root cause has become clear.
I was not testing 32KHz wav file.

In this case, (loop count mod 16) was not zero in
_vp_noise_normalize.

This question is corrected by RC4." -- Mebius1

This post has been edited by eloj: Mar 19 2005, 14:47

[eloj]

... and RC4 is out.

[rutra80]

Seems to work fine now

[rt87]

Bump for new version of Lancer 2005028 Release (Based on aotuv-pb4_20050412).

[rudefyet]

oh great....you made me wet my pants again

EDIT: Encoding from a pipe appears to be broken in this release

This post has been edited by rudefyet: May 28 2005, 08:08

[ilikedirtthe2nd]

Speed increased slightly on my system (AMD XP 1800+):

from 19.8x to 20.4x (3% speedup).

("Archer RC4" against "Lancer")

[eloj]

Run with the input file disk-cache hot.

Archer -q 6: 22,8144x, Average bitrate: 199,3 kb/s
Lancer -q 6: 23,2464x, Average bitrate: 195,5 kb/s

These speeds are wicked fast, so fast that any improvement is basically unnecessary.

I'd be more interested in what could be done to the decoder. I fear that the next generation sound cards and game consoles will have _greatly_ accelerated hardware decoding and mixing of "mp3", which might slow down or even _revert_ vorbis adoption by game devs -- which I consider today the largest and most important "market" where vorbis is successfully competing.

It would be a shame to see that happen. :-(

[Latexxx]

The next generation consoles won't ne pushing mp3. Microsoft will certainly push wma for Xbox titles and Sony its own Atrac3.

[de Mon]

Speed increased slightly on my system (AMD XP 1800+):

from 19.8x to 20.4x (3% speedup).

("Archer RC4" against "Lancer")

Why is the bitrate different? Rounding errors? If so - are theese versions safe to use?

[Josef K.]

Speed increased slightly on my system (AMD XP 1800+):

from 19.8x to 20.4x (3% speedup).

("Archer RC4" against "Lancer")

Why is the bitrate different? Rounding errors? If so - are theese versions safe to use?

If you mean bitrate diference between Archer x Lancer, the reason of course is the different version of the encoder (AoTuv b3 x AoTuv pb4), otherwise i didn't find any bitrate or filesize difference between Lancer [20050528] x original AoTuV pb 4 [20050412] (on which Lancer is based)
BTW I love it. I didn't expect they will release it so quickly. WONDERFUL !!!

[rutra80]

are theese versions safe to use?

We would need some listening tests to be sure...

[Bonzi]

are theese versions safe to use?

We would need some listening tests to be sure...

Not really, if you can determine that it produces identical output as AoTuv pb4 then you only really need to perform listening tests on AoTuv pb4 or Lancer.

[rutra80]

EDIT: Encoding from a pipe appears to be broken in this release

Pipe seems to work fine here.

are theese versions safe to use?

We would need some listening tests to be sure...

Not really, if you can determine that it produces identical output as AoTuv pb4 then you only really need to perform listening tests on AoTuv pb4 or Lancer.

Yeah, the point is that AoTuv & Archer/Lancer outputs are not identical. I don't know if due to different compilers or just the fact that SSE instructions are used, but they never were identical IIRC.

[rudefyet]

the bitrates are identical

but the resulting files differ in filesize by a few bytes (between lancer and aotuv pb4), i can't explain why

[sh1leshk4]

Is different vendor strings may be the cause of it (the few bytes difference)?
And yeah, piping works well in this version.

[rutra80]

Is different vendor strings may be the cause of it (the few bytes difference)?

Nope, actual audio data differs too.

[Gecko]

But the differences are only sporadic.
If you do a wave subtraction, you will see large amounts of absolute silence and a number of spikes.
I raised the question here but there was no final answer.

[Vax]

the size of aoTuV pre-beta4 [20050412] is 1.36 Mo
and the size of Lancer [20050528] is 401 Ko
why is there a such big difference of size?

[rutra80]

Lancer is probably packed with UPX or something and aoTuV is not.