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 optimized for speed (Read 255122 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

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)

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?

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?

Ogg Vorbis optimized for speed

Reply #78
Archer RC3 is out.
Nero AAC 1.5.1.0: -q0.45

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.

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.

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

Ogg Vorbis optimized for speed

Reply #82
... and RC4 is out.

Ogg Vorbis optimized for speed

Reply #83
Seems to work fine now

Ogg Vorbis optimized for speed

Reply #84
Bump for new version of Lancer 2005028 Release (Based on aotuv-pb4_20050412).
Sorry for my English.

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

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

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. :-(

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.

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

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?

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

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.

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.

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

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.

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.

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.

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?

Ogg Vorbis optimized for speed

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