Opus support? {Implemented with a 3rd party plug-in by thinktink)

[thinktink]

Not a whole lot of sudden downloads this time. Must've been only minor bugs this version fixed. Or it could be that people don't pay attention to forums posts at 1am in the morning...

[kzuse]

The previous version just works great for me But I just downloaded the new one and will probably test it this evening. (Oh, my timezone is UTC +0200 currently).

What is that gcc library for?

[kzuse]

So, tested the new build and works well (just as before) , but why does the new one need one extra DLL (the gcc one) that the previous version didn't need?

[thinktink]

Originally Posted by kzuse

So, tested the new build and works well (just as before) , but why does the new one need one extra DLL (the gcc one) that the previous version didn't need?

I'm assuming it's a shared library dependency from the MinGw compiler they used to compile the new libraries. If I don't distribute and pre-load that DLL before the others, the others won't load. Trust me, I tried. As for what it actually does, I have no idea...

[DrO]

it's only needed for dependencies generated on __moddi3 and __divdi3 according to dependency walker (just for LIBOPUSURL-0.DLL [both] and LIBOPUSFILE-0.DLL [only __divdi3]). at least it's only a 95kb file, but it seems a bit of a waste to have to include that as well just for what are likely simple methods to include natively in the compiles.

[kzuse]

Okay...

I also tested it of course and saw that it doesn't load But it's okay, it's not a specifically big file...

Moreover, the other dlls are some KB less in size now.

[kzuse]

Oh, and I've got the impression that the CPU load is less while decoding .opus files in this new release!

I have an older laptop on which playing OPUS resulted sometimes in stuttering when performing other high-load tasks, as encoding a video or surfing on complex Websites with Firefox. It seems that the new libraries somehow do a better CPU load management in terms of prioritizing their tasks or something like that. Or you optimized something in your decoding dll. It still needs more CPU load than decoding an MP3 file with Winamp's in_mp3.dll, which is rock-solid also on this old machine, but I guess MP3 is just not so complex to decode......

[thinktink]

Originally Posted by DrO

it's only needed for dependencies generated on __moddi3 and __divdi3 according to dependency walker (just for LIBOPUSURL-0.DLL [both] and LIBOPUSFILE-0.DLL [only __divdi3]). at least it's only a 95kb file, but it seems a bit of a waste to have to include that as well just for what are likely simple methods to include natively in the compiles.

Couldn't remember what order I load the DLLs so I actually had to fire up the laptop. It tells me I need to get back to coding ASAP despite my cold. GAH!

libogg loads fine without loading libgcc_s_sjlj first and so does libopus but libopusfile does fail to load without it. Can't say for the libopusurl dependencies because I don't feel like mangling my code to test it. I load libopusfile (post it's dependencies) before I load libopusurl and my wrapper code returns on failure if libopusfile fails to load before attempting to load libopusurl.

[thinktink]

Originally Posted by kzuse

...
Moreover, the other dlls are some KB less in size now.

Probably because libopusurl and libopusfile now share common code in libgcc_s_sjlj. There was no explanation that I found that explains why they decided to change it to an external dependency instead of just statically including the module in the libraries but I didn't look very hard either. At this point I'm only assuming they did it for size reasons.

Originally Posted by kzuse

Oh, and I've got the impression that the CPU load is less while decoding .opus files in this new release!

...

I think that was one of the rumored improvements of the new libraries but nothing official. Check the included Readme for official detailed changes.

[thinktink]

Originally Posted by Melkor

I found a couple of bugs. They might not even be your fault. If you make an opus file that is really long, weird things happen.

1) The "File Info" window reports PCM Frames as if it were a 32bit signed integer. The number being fed to it is an unsigned number, so if you have more that 2^31 frames, the number appears negative. Also if you have more than 2^32 frames, it silently overflows, loosing track of the real number of frames (my 34 hour file is reported as being about 9 hours).
2) The Playlist window seems to have the same problem, however if PCM Frames (as reported in the File Info window) are negative, winamp won't show a duration. If the frame count exceeds 2^32 frames and the resulting overflowed value is less than 2^31, it displays a wrong duration. So my 15 hour file shows no duration.

That said, when playing the file, winamp is able to get the correct remaining tracktime and to seek properly.

I'll be splitting the files to avoid the whole 32bit overflow as it seems to bug Rockbox as well (which is what I use for playback).

This is going to be hard for me to duplicate since I don't have anything I can use to spawn 15+ hour opus files from out of thin air to test with. If the file is too large even at smaller bitrates for you to transmit to me somehow, please post a screenshot of the tag editor window (Alt+3) for the file so I can see some of the stats that I can try to work backwards with.

Originally Posted by Opususer

Thanks a lot for the plug-in, it generally works very well.
When I have your plug in installed and update my media library which only consists of opus files winamp crashes. I found out this only is the case if there is an opus file in the libary which has a LOT of text in the meta-field "comment". (At least I hope this is called "comment" in the english version of winamp and I hope you know what I mean with "meta-field") Could this cause some kind of overflow?
Please let me know if I can help any further to find the root cause to this issue.

BogProgOpus1_3_22_77
Winamp 5.666 Build 3516 (x86)
Windows 8.1 x64

Yes, I would like a sample audio file that causes the error I can test against please. I have no measure for determining how much data is "a LOT of text" is to try to re-create locally. It should be able to handle any amount since I'm using a dynamic string handling class that can handle strings of any size, even insane lengths, so I need one of the actual files that causes the error so I can trace it down.

.

Originally Posted by Omega X

Is it normal that calculating ReplayGain sends the percentage to 200%?

I would think not, however I just tested it out on one of the test vectors I have and it did the same thing you described. However, I've never used the RG features of Winamp before and have no theories why, or even how, it could be happening. This will take time to investigate.

[DrO]

Originally Posted by thinktink

I would think not, however I just tested it out on one of the test vectors I have and it did the same thing you described. However, I've never used the RG features of Winamp before and have no theories why, or even how, it could be happening. This will take time to investigate.

it could also be a Winamp bug as there's been reports of that part showing weird percentages for a while (more so with very large files) that we still need to look into.

Originally Posted by thinktink

This is going to be hard for me to duplicate since I don't have anything I can use to spawn 15+ hour opus files from out of thin air to test with. If the file is too large even at smaller bitrates for you to transmit to me somehow, please post a screenshot of the tag editor window (Alt+3) for the file so I can see some of the stats that I can try to work backwards with.

changing to work with that ui element as an int64 type should be enough to blindly fix the issue

[thinktink]

Originally Posted by DrO

changing to work with that ui element as an int64 type should be enough to blindly fix the issue

You are correct for the fix, however, I would like to test it before sending it out.

[DrO]

you're no fun, heh

[MrSinatra]

just fyi, you can use audacity to make audiofiles as long as you like. just start with a long song and then paste it over and over to mixdown.

the RG thing is interesting, b/c I don't recall seeing that bug mentioned outside of this thread. Omega X did not say if his files doing so were long or not.

the RG plugin is supposedly open source and it used to say that the code for it would be published but that still hasn't happened. perhaps if it were, RG could be both fixed and / or updated to be a better plugin?

[DrO]

the percentage bug has been mentioned in another thread or two from memory (i think one of the bug reports - not 100% sure without checking my bug list archive), but it's more from non-forum methods that we've been made aware of it.

as for "the RG plugin is supposedly open source" - it's the library used which is just a straight compile of the source code for that library which is open source and as it's not been modified, there is no need to provide what is already available. unless you're mixing up and expecting ml_rg.dll to be open source as well, if so then that's not possible (and would somewhat defeat the point of Radionomy having just paid to get it and the rest of Winamp's source code).

[MrSinatra]

sorry to go OT, moving discussion to:

http://forums.winamp.com/showthread.php?t=376592

[thinktink]

I just stumbled upon a flaw where mono files being played back from libopusurl are played with pre-converted 2 channel audio being sent to an output plugin that thinks it's receiving 1 channel data, which results in the audio sounding twice as low and playing twice as slow. I didn't switch over all the code from my handler thread to libopusurl (oops.)

I also found out the real reason why the file lengths of super-long files are being displayed very improperly: I forgot to implement __fastcall UniString::UniString(__int64 U). Opus File returns the PCM length as a signed 64 bit integer but I was typecasting the result into a 32 bit so I could send it off to the UniCode class string constructor as a 32 bit integer temporarily. I was probably thinking I would implement it later and then forgot to do so. Oops.

ReplayGain is getting data from the Transcoder functions of input plugins. I tested in_bpopus's transcoder functions with in_bpxfade and everything seems fine, X-Fade is able to use in_bpopus just fine. However, since the other plugins don't seem effected I'm not giving up. I'll probably put temp code to outchuck the transcoder data to a temp file during the RG playback/calculation and inspect it to see if I can find anything wrong.

[thinktink]

I've gotten a little closer to the problem with RG going 200%. If I make the *_float versions of the transcoder functions inaccessible to Winamp then everything operates normally and the RG window finishes at 100% instead of 200%.


No *_float functions:




*_float functions accessible:




Note: The resulting suggested gain adjustments are the same between both but the calculated peaks are different.

[DrO]

can you send me a copy of the file you're using to test things with please and it'll make it easier to know i'm testing with the same thing, thanks.

[thinktink]

Originally Posted by DrO

can you send me a copy of the file you're using to test things with please and it'll make it easier to know i'm testing with the same thing, thanks.

Gimmie a bit and I'll also pop out two different versions of the plugin with and without the *_float functions as well.

[DrO]

i can disable the float access in winamp.exe as needed, so one version is enough

[thinktink]

Attached 7z file with a test vector and two versions of the plugin in different folders, one with *_float removed from the def and the other intact.

[DrO]

got it, thanks. will have a play with it once i've triaged an issue from the help site.

[thinktink]

I figured out what it was. I was calculating my sample-align after calculating the file size with an assumed sample-size of 2 bytes. After moving my sample-align creation to before the file size calculation and then using IT (4 bytes for floats) instead of the assumed 2 bytes it stops at 100% instead of 200%.


Before starting the in-depth investigation I thought maybe it was because I was outchucking the wrong type of float data. But after converting a test vector to MP3 and then viewing the raw contents of what it was outputting and comparing it to what I was outputting I found it was the same format. Therefore, the only other place I could look was at the format information I was passing back to Winamp during open(W)_float. So in lamen's terms, since I was under-reporting the final audio data length by exactly one half, Winamp would hit 200% because it was receiving twice the amount of data than I said it would receive.

I'll pop an update soon.

[thinktink]

Release (non-beta) version 1.4.24.89 is now available.

http://bogproghome.hopto.org/downloadwinampopus.html

Updates:

• Fixed issue with float transcoder functions that now report the correct final audio data length to the ReplayGain calculator (no longer ends at 200%.)
• Fixed monophonic non-local files hosted on remote http(s) servers playing back half as fast.
• Fixed issue with ultra-long files not reported with the correct length in various locations (UFIP, Playlist Editor window, etc...).

At the moment, I still have a cold.

[Aminifu]

Originally Posted by thinktink

At the moment, I still have a cold.

I hope you feel better soon. What you do for your craft is inspiring and a little crazy.

[MrSinatra]

TT,

that's really interesting. so would the same explanation apply to other formats that DrO said had reported the same thing? perhaps the other formats plugins need checked as well?

also, is it possible that what you originally thought is also the case? meaning, even tho u caught the 2 byte/4 byte issue, could it also be the case you are also outchucking the "wrong" type of float data? (just wondering if simultaneous issues have been ruled out?)

also, any theory as to why the peak values were different even tho the db was the same? (granted, the peaks were pretty close)

your opus plugin is becoming absolutely bulletproof while at the same time your efforts are even improving winamp! kudos.

[thinktink]

Originally Posted by MrSinatra

...

that's really interesting. so would the same explanation apply to other formats that DrO said had reported the same thing? perhaps the other formats plugins need checked as well?

I guess it's possible but I doubt it.

Originally Posted by MrSinatra

also, is it possible that what you originally thought is also the case? meaning, even tho u caught the 2 byte/4 byte issue, could it also be the case you are also outchucking the "wrong" type of float data? (just wondering if simultaneous issues have been ruled out?)

I don't believe so. What I did to test this theory was to compile a special debug build of X-Fade with "special" code in it to write out to a pre-determined file the output of the transcoder functions it was passing through from the other plugins it was hooking. I compared the output of in_mp3.dll and in_bpopus.dll in a hex editor and using GoldWave, a program I purchased a LONG time ago, which allows me to open raw or otherwise headerless audio data files while specifying a format. For both files, I had to select "Floating Point" format with the attributes "IEEE Single Stereo" and both files played normally.

Originally Posted by MrSinatra

also, any theory as to why the peak values were different even tho the db was the same? (granted, the peaks were pretty close)

To me, a value above 1 and a value below 1 are two very different things, especially if you're talking about audio data where 1 has a special meaning. As for a theory, nope.

Originally Posted by MrSinatra

your opus plugin is becoming absolutely bulletproof while at the same time your efforts are even improving winamp! kudos.

Not so much yet though. Still need more feedback from the other forum members who reported crash issues with metadata handling.

[MrSinatra]

your plugin is like, lightyears better, than that terrible movie.

but if DrO saw/got reports of the same 200% issue on other formats, than why would you doubt its the same type of cause? I'm not saying it for sure is, but it certainly would be something to look at I would think.

[DrO]

the reports were like 1139% on a single file (which were very long files iirc).

and that's good thinktink has sorted out the issue (was running behind so only just in a position to check now, but that doesn't seem needed now ).

[MrSinatra]

indeed, but do u have a theory about the peak values? TT made a good point about the importance of 0 re: audio levels.

[DrO]

i don't as i've not looked into it (and hadn't fully read all of the reply).

[thinktink]

Attached is an opus file inside a zip archive that is 32 hours of silence.

[thinktink]

I installed Wine on an iMac and installed a stripped down install of Winamp on it. Can't use Modern Skins. Anyways, I also installed the Opus plugin and everything seems fine. Can listen to local files and listen to online streams.

I was surprised it didn't take much doing to get it to work.

[thinktink]

Just as a shot in the dark to try to replicate the reported crash issues with opus files in the media library I created a short opus file and copy/pasta'd a short Chinese text sampler (complete with actual Chinese characters.) When I tried to import it into the library, it crashed. No error report or anything.

What I discovered was the difference between what the Winamp the core considers the length of a null-terminated string and what the Winamp ML expects.

When Winamp core reads the metadata, it tells the plugin "I can only hold 512 characters" in the "destlen" field. Here, it does not count the null terminator. If the metadata is longer than 512 characters then I chop it to 512 characters with dest[destlen]==0 and wcscpy it out so that I copy a total of 513 characters which includes the null terminator. No crash. If I go larger, el-crash-o of course.

Now when the ML asks for metadata, it says "I can only hold 1024 characters" in the "destlen" field. Here, IT DOES count the null terminator. If I chop it 1024 with dest[destlen]==0 then Winamp crashes when the function call returns.

So now I have to Chop(String,destlen-1) for all metadata calls. This means Winamp core will never get 512 characters, only 511, but now ML doesn't crash doing it this way.

I'll publish an update ASAP.

[DrO]

the buffer requests from Winamp (wherever it originates from) are meant to be used upto the size provided including the null character. and at times it can just be luck if you go over the buffer size that it won't crash (as some of the commonly crashing areas have a few extra bytes of buffer space to cope with things, but it's not guaranteed and doing anything beyond the buffer is then into unknown territory).

also the 2 crash reports i saw (though not looked at directly) showed you were on build 3512 and not 3516.

and what call specifically were you having issues with / wanting to have a larger buffer to work with?

[thinktink]

Originally Posted by DrO

the buffer requests from Winamp (wherever it originates from) are meant to be used upto the size provided including the null character. and at times it can just be luck if you go over the buffer size that it won't crash (as some of the commonly crashing areas have a few extra bytes of buffer space to cope with things, but it's not guaranteed and doing anything beyond the buffer is then into unknown territory).

Makes sense.

Originally Posted by DrO

also the 2 crash reports i saw (though not looked at directly) showed you were on build 3512 and not 3516.

Must've forgotten to update my plugin test install. My primary install is 3516. Thanks for the heads up.

Originally Posted by DrO

and what call specifically were you having issues with / wanting to have a larger buffer to work with?

A larger buffer was not really the issue but more surprised to see a difference between ML and core and the differing behaviors between the two than anything. I don't use the ML so this one basically slipped by me since I hadn't had issues with core, I figured it would be fine throughout.

[DrO]

Originally Posted by thinktink

Must've forgotten to update my plugin test install. My primary install is 3516. Thanks for the heads up.

and don't forget to revert the in_mp3.dll back from http://forums.winamp.com/showthread.php?t=156839#known2

Originally Posted by thinktink

A larger buffer was not really the issue but more surprised to see a difference between ML and core and the differing behaviors between the two than anything. I don't use the ML so this one basically slipped by me since I hadn't had issues with core, I figured it would be fine throughout.

things can vary from 256 to 400 to 512 to 1024 and some go higher. a lot depends on the original spec for the API which instigates the metadata calls as to what is used. the ML generally will request things with the larger buffer sizes, but 512-1024 is generally the size used for anything really to do with metadata (though obviously there are exceptions).

[thinktink]

Release (non-beta) version 1.4.25.91 is now available.

http://bogproghome.hopto.org/downloadwinampopus.html

Updates:

• Fixed crash issue with large metadata (comment) fields in the Media Library.

I still have a cold, but I think I'm coming up on the downswing of symptoms. Maybe.

[thinktink]

By the way, and I keep forgetting to mention this, I actually kinda liked that movie. It's funny (in a morbid sort of way sometimes), it has action, and an actual plot/storyline which more than you can say for some other movies.