I found a bug while using oggdropXPd V.1.8.9 using aoTuVb5 for Pentium 4 (2007-09-01).
When I encode some of wav files (not all) with that tool (-q 7) and then just select such files in the windows explorer by clicking them, the windows explorer shows me a bug warning and then hangs up.
I supposed it may be related on some directshow filterts or dBpoweramp software and uninstalled them, but the problem exists.
I tried oggdropXPd V.1.8.9 using libVorbis v1.2.0 for Pentium 4 (2007-07-27) and it doesn't produce such bug with same files. Does anyone have such problems?
I use Windows XP SP2.
If anybody wants, I can provide one of those wav files, that produce the bug.

I've personally never seen anything like this, nor have I had any previous notification of anything like this. However, if you can make a 'suitable' file available, I'll certainly test it. I have to say that I would like to have seen more of an explanation than "... the windows explorer shows me a bug warning and then hangs up." as this really tells me nothing.

There will be a shell extension which is crashing (if it is explorer.exe that is crashing). By default Windows Explorer will not look inside .ogg files.

Hmmm, sounds about right. Thanks for the input.

Ok, here is a zip archive with screenshot of window, that appears after I select a file. Also it contains one of such bug-generating wave-file:

http://www.sendspace.com/file/2r9wxt

Translation from Russian:
explorer.exe - an error is detected. The application will be terminated. We apologize for inconvenience. and blah-blah-blah - windows warns and offers to send error data...

After that window appearing all explorer windows and many of my tray icons disappear.

Spoon, can you explain, what did you mean: "There will be a shell extension which is crashing (if it is explorer.exe that is crashing). "?

Well, I've downloaded the file, encoded it with the same encoder, at the same 'q' level. I can select it in Explorer with no error condition, double-click on it and have it play perfectly in foobar!

What spoon is referring to is an add-on to Explorer that provides additional functionality beyond what is within Explorer natively. The suggestion is that it is this that is causing the problem.

Yes, my file is also played perfectly (by Winamp), but when I select it, the explorer crash appears.
The only addon for explorer I use is dBpoweramp extended info for media files.
But the bug appears also without dBpoweramp addon.

I've read in wiki, that aoTuVb5 is recommended vorbis encoder but it now seems to me strangely, when I experience many problem with it. Also it crashs itself from time to time, when I try to decode an ogg file.

So, why aoTuVb5 is recommended, but not XPd using libvorbis 1.2.0?

I've tried to encode that wav file with oggdropXPd V.1.8.9 using aoTuVr1 для Pentium 4 (2006-08-23) (fortunately, I keep this old version on my hard drive!) and there weren't any bugs, it works perfectly!

Another idea came to me: some problem may exist in additional libraries, that I downloaded for the new version of aoTuVb5. I had no msvcr71.dll in my system and I downloaded it somewhere from the net.
What do you think of possible bugs in external libs? Previous versions of aoTuVb5 weren't buggy, may be due to they didn't require any external libs?

looks like a Windows issue... not OGG itself...

Is it possible that oggdropXPd create some non-ansi tags (cyrillic symbols in unicode for example)?
BTW, I don't know if this program has such functionality so, sorry if my question is irrelevant.
~

As I've not received any other reports of this, and I don't experience any errors myself (on a variety of systems, I might add - Intel and AMD based, all XP Pro SP2), you seem to be alone with this problem. This strongly suggest that it is some other issue.

It is recommended because, particularly at the lower quality/bitrate settings, it is more highly tuned. If you always encode at 'q 7', and this encoder does not cause you any problems, then you should try it as you are unlikely to notice any difference in quality in the encoded files.

Same comment as for the 1.2.0 version.

The b5 libraries have been extensively tested with no indications of any problems. External library dependency is unchanged as between the versions you mention.

@Tropidont
I expect that there is a problem for installed shell extension. I really know that specific shell extension causes a problem.

I don't think the problem with unicode, because I don't order the XPd to create any tags. Besides, Win XP, as I know, supports UTF-8.

So, if I choose between XPd using libvorbis 1.2.0 and an older version of aoTuV (V.1.8.9 using aoTuVr1, 2006-08-23), what could you advice?
I plan to encode a lot of music files of contemporary and classical music for my personal archive, all with -q 7 (AFAIK, this -q setting is a good solution for audio quality with no sacrifice of disk space).

And I still can't hear any difference between source and encoded file. But who knows, may be some difference will be on some types of audio material?



@Aoyumi,
could you explain it for me?
Am I able to make any fixes of that problem for my system?

Shell extensions are little helper programs that usually, when you right-click on a file, show some additional options in that menu what you can do with file. By default there are copy, cut, paste, delete, send to... but there is something in that right-click menu that crashes when you click on these new oggs for whatever reason. There was a program which could selectively disable shell extensions, but I can't recall the name of it, you should google it up and try to pinpoint shell extension that troubles you.

Please see the following link.
You may do defeasance of specific shell extension by using the tool.
http://www.nirsoft.net/utils/shexview.html

OK, colleagues, I deactivated the Shell extension named "Video Thumbnail Extractor", that extract properties for media files and explorer isn't crashed now, when I select that .ogg file.
What next?

I think you've found the answer, haven't you? Clearly that extension is doing something it shouldn't and you would be best advised to remove it.

Yes, thanks all for the help, but I'm just curious about the reason of such strange behaviour of this new version of the XPd codec.
Why didn't older versions make such 'corrupted' .ogg files, conflicting with my shell extension?

And what about a decision on a codec for my archive (see above), what do you think?

We would probably need to know how the extension worked to answer that, but I will concede that it is odd that it should only happen occasionally with b5 files.

To be honest, I think you could use any of the three versions at 'q 7' and never tell the difference between them. I think all three produce results that are, or are near, transparent to most people at that 'q' level.

It is not advised to install shell extensions in Windows Explorer.

@Aoyumi
Offtopic a bit but since you poped in here...
In topic http://www.hydrogenaudio.org/forums/index....showtopic=51289
there's a user commenting on aotuvb5:





I have seen the same thing, the low level noise in several settings (q5, q6, q7...) what's your words on this?

>It is not advised to install shell extensions in Windows Explorer.

Why? we have been doing it for 5 years and have minimal problems with shell extensions. You know that Microsoft have in built shell extensions already for say mp3 and wav, if you ask me, our routines are more robust than Microsofts...

Well, I think my problem isn't related to dBpoweramp extensions. The issue is here in my system:
C:\WINDOWS\system32\shmedia.dll
This file somehow conflicts with some .oggs, encoded by beta 5 XPd

I'm not saying your shell extension is broken... I'm saying Windows is broken (in many ways).

I do not have a clear answer about it.


It is my mistake. I will include the revision in a future version. However, I think that there is not the big problem acoustically.

"in a future", you mean, July next year probably? Oh man, I can't wait that long.

Perfection takes time.

If somebody performs blind listening tests about the revision, I may show a new binary and source code. I usually perform blind listening tests before showing a new version. However, I do not intend to do it now. It is after a prospect of the next release arrives.