thnx

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

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?

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.

I used the build from this url.

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



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



Ideas?

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

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

My mistake... correct data:

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

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



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

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.

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'!

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


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

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.

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

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

Archer Release-Candidate 1 is out.

Thanks. Now is the time to test again.

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:

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

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.

I can confirm the bug here too:



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+ :



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

Archer RC2 is out.

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.

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


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.

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)

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

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

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

Archer RC3 is out.

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.

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.

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


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

... and RC4 is out.

Seems to work fine now

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

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

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

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

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

("Archer RC4" against "Lancer")

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

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

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

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.

Pipe seems to work fine here.

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.

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

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

Nope, actual audio data differs too.

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.

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?

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