Skip to main content

Topic: Ogg Vorbis optimized for speed (Read 208815 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • eloj
  • [*][*]
Ogg Vorbis optimized for speed
Reply #75
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)
  • Last Edit: 18 March, 2005, 04:08:14 PM by eloj

  • Josef K.
  • [*][*][*]
Ogg Vorbis optimized for speed
Reply #76
Quote
What's the point of posting the report at a forum the developer probably doesn't read?
[a href="index.php?act=findpost&pid=283291"][{POST_SNAPBACK}][/a]

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...
Quote
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)
Is there a difference between yes and no?

  • Josef K.
  • [*][*][*]
Ogg Vorbis optimized for speed
Reply #77
Quote
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)
[a href="index.php?act=findpost&pid=283381"][{POST_SNAPBACK}][/a]

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
Is there a difference between yes and no?

  • DreamTactix291
  • [*][*][*][*][*]
  • Members (Donating)
Ogg Vorbis optimized for speed
Reply #78
Archer RC3 is out.
Nero AAC 1.5.1.0: -q0.45

  • eloj
  • [*][*]
Ogg Vorbis optimized for speed
Reply #79
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
  • [*][*][*][*][*]
  • Members (Donating)
Ogg Vorbis optimized for speed
Reply #80
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.
  • Last Edit: 19 March, 2005, 07:33:02 AM by rutra80

  • eloj
  • [*][*]
Ogg Vorbis optimized for speed
Reply #81
I can confirm that 32KHz files don't work at all at negative quality settings:

Code: [Select]
.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
  • Last Edit: 19 March, 2005, 08:47:20 AM by eloj

  • eloj
  • [*][*]
Ogg Vorbis optimized for speed
Reply #82
... and RC4 is out.

  • rutra80
  • [*][*][*][*][*]
  • Members (Donating)
Ogg Vorbis optimized for speed
Reply #83
Seems to work fine now

  • rt87
  • [*][*]
Ogg Vorbis optimized for speed
Reply #84
Bump for new version of Lancer 2005028 Release (Based on aotuv-pb4_20050412).
Sorry for my English.

  • rudefyet
  • [*][*][*]
Ogg Vorbis optimized for speed
Reply #85
oh great....you made me wet my pants again

EDIT: Encoding from a pipe appears to be broken in this release
  • Last Edit: 28 May, 2005, 03:08:10 AM by rudefyet

Ogg Vorbis optimized for speed
Reply #86
Speed increased slightly on my system (AMD XP 1800+):

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

("Archer RC4" against "Lancer")

  • eloj
  • [*][*]
Ogg Vorbis optimized for speed
Reply #87
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
  • [*][*][*][*][*]
Ogg Vorbis optimized for speed
Reply #88
The next generation consoles won't ne pushing mp3. Microsoft will certainly push wma for Xbox titles and Sony its own Atrac3.

  • de Mon
  • [*][*][*][*]
Ogg Vorbis optimized for speed
Reply #89
Quote
Speed increased slightly on my system (AMD XP 1800+):

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

("Archer RC4" against "Lancer")
[a href="index.php?act=findpost&pid=301129"][{POST_SNAPBACK}][/a]


Why is the bitrate different? Rounding errors? If so - are theese versions safe to use?
Ogg Vorbis for music and speech [q-2.0 - q6.0]
FLAC for recordings to be edited
Speex for speech

  • Josef K.
  • [*][*][*]
Ogg Vorbis optimized for speed
Reply #90
Quote
Quote
Speed increased slightly on my system (AMD XP 1800+):

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

("Archer RC4" against "Lancer")
[a href="index.php?act=findpost&pid=301129"][{POST_SNAPBACK}][/a]


Why is the bitrate different? Rounding errors? If so - are theese versions safe to use?
[a href="index.php?act=findpost&pid=301224"][{POST_SNAPBACK}][/a]

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 !!!     
Is there a difference between yes and no?

  • rutra80
  • [*][*][*][*][*]
  • Members (Donating)
Ogg Vorbis optimized for speed
Reply #91
Quote
are theese versions safe to use?
[a href="index.php?act=findpost&pid=301224"][{POST_SNAPBACK}][/a]

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

  • Bonzi
  • [*][*][*][*]
Ogg Vorbis optimized for speed
Reply #92
Quote
Quote
are theese versions safe to use?
[a href="index.php?act=findpost&pid=301224"][{POST_SNAPBACK}][/a]

We would need some listening tests to be sure...
[a href="index.php?act=findpost&pid=301284"][{POST_SNAPBACK}][/a]


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
  • [*][*][*][*][*]
  • Members (Donating)
Ogg Vorbis optimized for speed
Reply #93
Quote
EDIT: Encoding from a pipe appears to be broken in this release
[a href="index.php?act=findpost&pid=301090"][{POST_SNAPBACK}][/a]

Pipe seems to work fine here.
Quote
Quote
Quote
are theese versions safe to use?
[a href="index.php?act=findpost&pid=301224"][{POST_SNAPBACK}][/a]

We would need some listening tests to be sure...
[a href="index.php?act=findpost&pid=301284"][{POST_SNAPBACK}][/a]

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.
[a href="index.php?act=findpost&pid=301289"][{POST_SNAPBACK}][/a]

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
  • [*][*][*]
Ogg Vorbis optimized for speed
Reply #94
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
  • [*][*][*][*]
Ogg Vorbis optimized for speed
Reply #95
Is different vendor strings may be the cause of it (the few bytes difference)?
And yeah, piping works well in this version.

  • rutra80
  • [*][*][*][*][*]
  • Members (Donating)
Ogg Vorbis optimized for speed
Reply #96
Quote
Is different vendor strings may be the cause of it (the few bytes difference)?
[a href="index.php?act=findpost&pid=301336"][{POST_SNAPBACK}][/a]

Nope, actual audio data differs too.

  • Gecko
  • [*][*][*][*][*]
Ogg Vorbis optimized for speed
Reply #97
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
  • [*]
Ogg Vorbis optimized for speed
Reply #98
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
  • [*][*][*][*][*]
  • Members (Donating)
Ogg Vorbis optimized for speed
Reply #99
Lancer is probably packed with UPX or something and aoTuV is not.