oggdropXPd V1.8.7, oggenc2.8 and oggdec V1.9.2 released 2005-12-08.

All the above version updates are to handle multi-channel input and output correctly in relation to WAVEFORMATEXTENSIBLE conforming input and the channel mapping as defined in the Vorbis I Specification. The decoders handle channel mapping correctly for output to file, and for playback, creating WAVEFORMATEXTENSIBLE conforming output. The decoders also offer the option to downmix multi-channel audio, conforming to the Vorbis I Specification, to stereo. These versions are based on libogg 1.1.3 and libvorbis 1.1.2/aoTuVb4.51.

All flavours are at Rarewares now.

Thank you very much indeed, appreciated.

Nice. Updated the recommended encoder thread with the new versions. Also updated the static linux binaries of vorbisgain and oggenc to aoTuV beta 4.51.

Sorry I think I missed something...

libvorbis is now 1.1.2 ? how does it relate to aoTuVb4.51 ?

libvorbis 1.1.2 is the official Vorbis library coming out from Xiph.Org that is mostly based on the old aoTuV beta 2. aoTuV beta 4.5 is Aoyumi's tuned version of libvorbis (based on libvorbis 1.1.1).

It don´t have any important improvement in quality, I check the changelog and it mostly fix one bug...


In fact... the libvorbis 1.1.2 has the same signature that the 1.1.1 "Xiph.Org libVorbis I 20050304".... I really want to know what the Xiph guys are doing... If Aoyumi don´t release his great Aotuv, vorbis can´t compete with AAC. Even LAME has evolved a lot more...

IIRC, aoTuVb4.51 was actually based on the then current SVN version, ie., post 1.1.1, and did include the bug fix referred to in the release notes.

This versions support 5.1 channel coupling? or is just the correct way to output each channels in the correct order?

Sooooo... let me get this straight:

Xiph 1.1.2 is a bugfix of Xiph 1.1.1 which incorporates aoTuVb2.

aoTuVb4.51 is a bugfix of aoTuVb4.5 which is an improvement of aoTuVb4 which -ultimately- is based on Xiph 1.1.1.

aoTuVb4.51 already incorporates the bugfixes of Xiph 1.1.2.

So in conclusion: I should be using the aoTuVb4.51.

Am I reading this correctly?

No channel coupling, they just maps channels in the correct order when encoding and decoding.

Yes and yes, if I understand you you correctly!!

I think this has definitely been asked before, but I'd like to know if anyone could tell what the main differences are between the available 3 versions:
- Oggenc2.8 using libVorbis v1.1.2
- Oggenc2.8 using libVorbis v1.1.2 with IMPULSE_TRIGGER_PROFILE Option
- Oggenc2.8 using aoTuVb4.51

Recently I made some samples @ Q4 (128Kbps) > the libVorbis produced me 116Kbps (3.180.453 bytes) file, and the aoTuVb produced me a 118Kbps (3.232.446 bytes) file.
I didn't notice any soundquality differences though...and I also noticed QuantumKnot recommends the aoTuVb version in his Recommended Encoder Versions and Settings thread...Why? What makes this version so special above the libVorbis version?

Haven't you noticed QuantumKnot's explanation in the same thread?

Ah... it bears your name... that must be the reason

Hehe j/k. Lighten up!

Peace

No, latest Lancer

sarcastic note: those 'yellows' (Japaneses) are great !

Wow! This Lancer built is well above 40x encoding here. Never tried it before.
I somewhere read it "may" produce different results due to its optimisations. Is there a degraded example documented?

If you're unsure about the result, do the following:

a) choose a sample and encode it with oggenc (let's call it sample X);
b) encode that sample with lancer (sample Y);
c) open both of them with a sound editor;
d) flip/invert one of them;
e) mix them (by this operation, you subtract X from Y, or vice versa — depending on which one you've flipped; the result will be identical);
f) see if there is something left (if the aforementioned samples are identical, there shouldn't).

Cheers.

edit: gr.

All compiles deliver different results. So does the Standard, AMD/P3 or the P4 compile. It is no wonder the Lancer does a bit different also.
I just asked if there is a documented "problem" about the Lancer build just cause of its optimizations in the code.

Ah, sorry, I somehow misread your post.
Well, as for now, there weren't any documented and/or well-known problems with Lancer, AFAIK.

I also hinted in another thread that the optimized code might affect quality. But I am going to retract that notion and venture toward the hunch that different compilers have different ways to derive equations with math, then results (in the case of perceptual audio) are approximately the same.

Actually I have no idea what the hell I'm talking about

Thanks: john33, Aoyumi, the Blacksword guys and all the testers ..and Xiph people
(I use the latest encoder music excerpts at [geocities slash feedthedead slash palehalf] and, no, this is not plug- just sharing

Ah this question I had asked previously in this thread.

Basically, the answer is like this:

Lancer uses SSE, and this rounds off floating point numbers differently than the, um, plain aoTuVb4.51.

However, despite the differences, I have tried them both and to my ears they sound the same.

So i think it is safe. There once were discussions about small differences in lame´s output due to compiler optimisations. No one ever reported a sound problem cause of this. The differences are just to small.
Thanks for your input.

Dunno if anyone tests these in Win x64, but I tried both aoyumidrop and lancerdrop; they both began promisingly encoding about half of the dozen FLACs, but then the fish stopped and the drop ability was gone. Those files which had been encoded were fine. It seems to me that these Oggdrops also borked MediaCoder.
I wound up doing a System Restore and all is well again. But I'm sticking with MediaCoder pointed to Lancer's oggenc2.exe .

Looking at the xiph bugtrac I see there are some ticket with problems and patches for OggDropXP.
I don't know if they are yet valid, in this case they should be closed.

That's the general consensus that I am came to and what I have written down on the page in the wiki. I have read about SSE instructions in the past, but it's been a while.

Why oggenc2.8 encoded files not played by http://www.illiminable.com/ogg/ ?
Atlon XP 3200+

I registered to HA finally, after reading it for so long, so hi guys.

Let me start with a question about OggDropXPd:
Why is it that specific FLAC's are not decoded by it?

Can't seem to figure that one out.

I can, however generate one of those flac's for you by using EAC, and setting it to directly rip to FLAC, directed to the latest 1.1.2 flac.exe with the following commandline:




+++ UPDATE +++
I found out why by trying some stuff.... It was the genre tag made oggdrop quit without errormsg, log or whatever. The genre line was like this:
GENRE = Alternative Rock
With a genre tag like: GENRE = Misc it's all ok.

Might it be the space in "Alternative Rock"?

Welcome. It's always more fun as a member.

Can you tell me exactly what options you selected?

As a matter of fact I had none selected, because I deleted the .ini during trying other stuff.

So all the settings in the Tagging Setup where at their defaults.

The only changes i made to the default setting (ie, after deleting the ini) was:
- Set ogg q to 7.00
- delete input file to true

Not that I think it relates, but which compile are you using?

Clearly there is a problem somewhere, but what puzzles me is that with the default tagging settings, no tagging takes place which means that no attempt is made to process the FLAC tags in any way.

Even if the option to copy the FLAC tags was set, the length of the Tag is determined by reading the tag length variable rather than relying on any terminator within the tag data, so the content of the Tag shouldn't be relevant.

Have you tried encoding using oggenc2.8? This uses identical routines for processing FLAC input files. If you don't want to copy the FLAC tags, you'll have to add the option '--discard-comments' to the command line. Actually, these routines are identical to those in the standard oggenc.

Hi John,
Can you comfirm this problem which is exists in oggenc 2.8 or not?
If so, is there's any fix for it?

Thanks in advance.

This quote suggests to me that the problem is elsewhere. The processing via "stdin" is unchanged from the standard oggenc from xiph.

I would need to know exactly what is being passed from dbpoweramp to make any other comment.

oggdropXPd V.1.8.7 using aoTuVb4.51, P4 Only


If it helps I can add it doesn't even try to do anything. No reaction on drop whatsoever.


Again, using "Alternative Rock" for GENRE did NOT work, and using "Misc" did.
BUT: I just tried to set the GENRE back to Alternative Rock and now it works!
Could it be that the tags are corrupted in some way that foobar can read them still?


I haven't tried that. However, I will first try to recreate the erroneous flacs tonight, because by resetting the GENRE they all work now, so there's not much to test with anymore.

It does rather sound like the tags are malformed in some way, but do keep me informed. Clearly if there is a problem, I'll try to fix it, but it is also necessary to identify exactly the nature of the problem.

You're right, STDIN is fine. But the raw(pcm) file/stream input doesn't work in oggenc 2.8.

yup, raw pcm input isn't working in oggenc 2.8

in the case of dbpoweramp... sense all the commands are the same from the previous lancer release (2.6 aint it?) it should have been just a quick swap of the executable (since piping works fine with that version). I have also tried sending the wave riff too, but that didn't work either. Other than that I don't know, I haven't actually tried anything more after that 10min or so. I just reverted back to the previous version ... maybe I'll try more stuff in a week (spring break and I'll actually have free time.. maybe)

And you're right, too!! I've uploaded oggenc2.81 in all varieties to Rarewares. I believe this fixes the raw input and aiff file processing, both of which I broke when I added the corrected multi-channel processing.

Ok, you could say that this is a bug in OggdropXPd that I just ran across. When you specify a specific directory to output to, you just type it in manually, and you type in more than one non-existing directory deep, you get "cannot write to location"-type errors, instead of it creating that folder structure.

John, btw, is there any chance you could write in that code again that would allow me to set a "Start at Logical Stream Number" value, and also be able to "Disable incrementing of serial number"? I am doing some more bit difference testing, and I need to be able to use OggDropXPd with the latest builds of the Pentium 4-optimized Vorbis encoders to do that stuff in batch again. If you have lost the code, I can at least send you the executable from before so you can see how you had the option menu configured (yeah, I know it wouldn't help you code it again, though).

That's standard functioning with what's available with the VC6 compiler. I've produced a VC7.1 based ICL9.0 compile that adds the option to create a new folder in the folder browser window when specifying a different output folder; you can d/l it from: http://homepage.ntlworld.com/jfe1205/oggdr...dV1.8.7b-P4.zip. Can you let me know what you think? Personally, I think this is a better route than allowing typing in the edit box. I'll add this to the temp dir option, as well.

Can you mail me the exe and I'll see what I can do for you.

Even I recommend using LANCER .... Yes it is very fast!

It was optimised for 2x speed retaining the same quality!!

Yeah, that is agreeable, because it at least solves having to go and browse to the location in a Windows Explorer window manually to create a new folder structure for a set, and also you don't have to go and code anything separately. Using that, I shouldn't need to have to type it in manually.

The thing that this doesn't fix, however, is the case where someone goes and deletes the "more than one deep" folder structure later, because then it will still bug out the next time you use the program. It might be helpful for you to code the program to check on startup whether the Output and Temporary folders still exist, and prompt the user if they don't, instead of having it bug out when you start encoding. Just imho, that is.


I sent you a link to download it. Thanks!

Would it be possible to also include direct encoding from WavPack files in OggdropXPd, as it already does this for Monkey's Audio, LPAC, FLAC and OptimFROG? WavPack is under BSD license, so that part at least shouldn't be a problem.

I'll look into it and get back to you.

I have a test version running that uses a very simple wvunpack dll that I created. It seems to run as expected but I need to do some further testing and I also want to add one or two other changes before I release a new version.

Thanks, mate! Take your time, take your time...

Well, I believe I have a solution for mmortal03 and for Mr_Rabid_Teddybear, so I should be able to put a new version out in the next few days after some more testing.

Right, and would you please do it using aotuv prebeta 5, if this is possible John33.

Thanks

As soon as the source becomes available, sure. Right now, there is just a stripped down oggenc available.

Mmmmmm.. btw...the link to prebeta5 *clearly* states : "Quality -1 only!". I believe we should AT LEAST believe the guy...

oggdropXPdV1.8.8 is now available at Rarewares.

Now includes direct input of Wavpack files with, or without, correction files. Also, the Output Directory Dialogue has been updated. Previously, a saved output directory that was subsequently deleted and was more than one level deep would cause an error. This is no longer the case, it will be recreated however many levels deep.

The consequence of this is that Windows 2000, or better, is now required. These are MSVC7.1/ICL9.0 compiles. The wvunpack.dll required for Wavpack input is available for separate download. As before, if you're not going to input Wavpack files, you don't need this.