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

[kzuse]

Or if your alac files are called .m4a, it works right out of the box, does it?

[Kaminari]

Sure. Though many ALAC files outside of the iTunes microcosm use the ".alac" extension.

The only reason why Apple adopted the ".m4a" extension is because the ALAC codec, which is not related to MPEG-4 at all, is nevertheless muxed in a MP4 container. However many MP4 players can't decode the ALAC codec.

Winamp Essentials

[thinktink]

Here we go, this should fix the fade out on stop issue. Attached.

[kzuse]

Great! Works!

(Continued off-topic about ALAC:
So, actually a MP4 container containing ALAC is actually NOT an MPEG-4 conforming file, as ALAC is not mentioned in the MPEG-4 specs. Even if the MP4 container is well in conformity to the standard...
But if Apple released it to the public now, I very well could imagine that some day ISO will adapt it and iclude it into the MPEG-4 standard maybe...

Anyway, iPhone and iTunes play them, I tried, but I still need to try on my old 5G iPod (2005)... I could imagine that it also plays them though I'm not sure.

On the other hand, my Panasonic Blu-ray player plays .flac files very well (from USB, disc or DLNA) but it does not ALAC (it even does not play .M4A AAC files from USB, which ist stupid - only .mp3...)

(Sorry for my off-topic posting)

Best regards,
kzuse

[MrX_1980]

Hi thinkthink,
with your in_bpopus.dll the ogg streams are crashing (http://forums.winamp.com/showpost.ph...0&postcount=99)

It would be better if in_bpopus.dll will be only used for .opus and not for .ogg
Is it possible ?

[thinktink]

Originally Posted by MrX_1980

Hi thinkthink,
with your in_bpopus.dll the ogg streams are crashing (http://forums.winamp.com/showpost.ph...0&postcount=99)

It would be better if in_bpopus.dll will be only used for .opus and not for .ogg
Is it possible ?

It is only used for opus and not vorbis. I've dropped the stream into both the release 5.623 and the latest Beta build of Winamp and I'm not seeing your issue. I can hear the stream fine. You're gonna have to provide a more complete report about your current Winamp install.
http://forums.winamp.com/showthread.php?t=161361#specs


Your crash report stated that the faulting module is "GDI32.dll" and not "in_bpopus.dll" so that's going to take a while to try to debug if my plugin is the actual source of the problem.

[MrX_1980]

Mhhh, if I start the ogg streams I see "Decoder: Nullsoft Vorbis Decoder v1.71" but it only crashes if also the in_bpopus.dll (1.1.10.21) is in the plugin folder. If I remove the in_bpopus.dll then the streams are ok.

opus dll's I use:
https://ftp.mozilla.org/pub/mozilla....-0.2-win32.zip

On WinXP it crashes without any Windows event entries.

dump files of Debug Diagnostic Tool:
http://remixshare.com/dl/9cswm/Crash...winamp.exe.zip

With the classic skin it is working, but not with Modern skin or Bento.
In the CrashHang Report I see "gen_ff.dll has caused an unknown exception"

[thinktink]

Ok, I've been able to reproduce the crash in the logs and dumps you provided in this thread (but not the other you linked to previously.) I kinda know why it's crashing but not really. Watch for another post.

[EDIT/]
Update:
http://forums.winamp.com/showthread....65#post2921065

[EDIT=2/]
Update 2:
http://forums.winamp.com/showthread....66#post2921066

[MrX_1980]

Winamp -> Open URL -> http://people.xiph.org/~giles/2012/o...lights-96.opus -> HTTP/1.1 404 Not Found
But the file exist (playable with Firefox)

Winamp or in_bpopus bug?

[DrO]

moved to plug-in thread.

if in doubt assume the plug-in as the first starting point (as streaming is typically done via the plug-in or at least started off by it).

[ujay]

Hi MrX,

I'm dragging and dropping the link you give to Winamp's main window.

I get [HTTP 200 OK] followed several seconds later with [Error syncing to stream].

This usually means Winamp is connecting but can't find a suitable input plugin.

UJ

[MrSinatra]

UJay,

was that with TT plugin installed and with the .opus ext associated?

[ujay]

I've added in_bpopus.dll. Is that all that's needed ? This thread is a bit of a mess and difficult to find what's what.

Just removed it again though as it seems to be crashing ogg streams.

Association shouldn't matter if the stream is passed directly I think.

UJ

[kzuse]

You also need to place the opus codec libraries (dlls) in to the Winamp\Plugins folder.

You will find them here:
https://ftp.mozilla.org/pub/mozilla....-0.2-win32.zip

[ujay]

Thanks kzuse, thought there was probably a lib file involved somewhere.

It's playing a few files I've found OK.

Getting 404 on the stream posted above now, but others(Absolute Radio) are fine.

Still crashing ogg streams though.

UJ

[thinktink]

Originally Posted by ujay

...Association shouldn't matter if the stream is passed directly I think...

No, it shouldn't. It's crashing for different reasons. See links posted above about the ogg stream crashes.

Originally Posted by MrX_1980

Winamp -> Open URL -> http://people.xiph.org/~giles/2012/o...lights-96.opus -> HTTP/1.1 404 Not Found
But the file exist (playable with Firefox)

Winamp or in_bpopus bug?

Attached new version that doesn't escape forward slashes.

[thinktink]

Just a reminder. To listen to Opus streams that don't end in ".opus" replace the http:// part with opus://

[ujay]

Hi thinktink, That stream is playing OK now, doesn't show a bitrate, but sounds like a good codec.

One thing I notice is that the stream is not letting go properly if you use the STOP button(goes buffer hunting). Finishes OK if you let the stream play out though.

UJ

[thinktink]

Originally Posted by ujay

Hi thinktink, That stream is playing OK now, doesn't show a bitrate, but sounds like a good codec.

It only shows the bitrate of the first segments (which is usually not correct) on streams. I tried updating the bitrate info during streaming playback but it completely messed up the classic skin rendering system so I had to remove it.

Originally Posted by ujay

One thing I notice is that the stream is not letting go properly if you use the STOP button(goes buffer hunting). Finishes OK if you let the stream play out though.

Huh? Not following your meaning. Maybe a screenshot would help.

[ujay]

Press STOP and a line runs back and forth across the SA.



Also, notice M4A streams are broken too, same issue as OGG ???

UJ

[MrX_1980]

Originally Posted by thinktink

Attached new version that doesn't escape forward slashes.

Thanks, it is working now.
Great job

[thinktink]

Originally Posted by ujay

Press STOP and a line runs back and forth across the SA.

Looks like a false buffer hunt indicator though it's probably something I forgot. Will have a look.

Originally Posted by ujay

Also, notice M4A streams are broken too, same issue as OGG ???

Probably.

[thinktink]

Fixes previous leftover buffer hunt.
Includes Encoder.
Removes DLL's from Plugins folder and extracts the (same) DLLs to the root folder (at the behest of DrO.)


The experimental encoder works only with incoming audio that has a sample rate of 48, 24, 12, 6, or 3 KHz.

[kzuse]

I would be very glad if you could please continue providing the individual decoder DLL?

I'm not a friend of running installers when I know exactly what to do to install, while installers usually do something more than that (don't get me wrong, it's not that I don't trust your installer!). Would be great.

@DrO - Isn't it actually much more cluttering to place those supporting DLLs into Winamp's root folder instead of the plugins folder? But okay, not so important...

[DrO]

it was only a suggestion / observation as it seemed to have caused unwanted 'not working' reports due to there not being a simple installer to sort all of this out, it wasn't a requirement.

dumping them in the root of the winamp folder or even the plugins folder isn't ideal. ideally there should be a 'supporting library dll' folder... so dlls like the opus ones, etc can be put so as not to clutter up the root of the winamp folder (or cluttering up the plug-ins folder).

[MrSinatra]

Originally Posted by DrO

dumping them in the root of the winamp folder or even the plugins folder isn't ideal. ideally there should be a 'supporting library dll' folder... so dlls like the opus ones, etc can be put so as not to clutter up the root of the winamp folder (or cluttering up the plug-ins folder).

can something like that be added by the devs, as "another" location to check / look for such things, so as not to break anyones current exp but add the feature going forward?

along the same lines, I wish there was a "3rdparty" plugins subfolder to the main plugins folder, so they would not get tangled together.

[thinktink]

Sounds like I need a better NSIS installer script template for plugins.

[thinktink]

Originally Posted by MrSinatra

along the same lines, I wish there was a "3rdparty" plugins subfolder to the main plugins folder, so they would not get tangled together.

No thank you! A fair number of my plugins rely on them being installed into the same directory as the core ones. This includes, but is not limited to, X-Fade and LiveWire (for DSP stacking.) And there are probably other plugins this little suggestion would break.

[thinktink]

Completely close (all instances of) Winamp before installing.

Fixes:

• Fixed hang on stop issue for streams still in the lookup stage.
• Reconfigured installer to drop supporting dlls into a seperate folder in the root install folder (libopus.) Also removes any of the (now) misplaced supporting DLLs.
• Installer now extracts "README.txt", "COPYING", and "AUTHORS" which is a legal no-no to not do when redistributing the support DLLs.

[MrSinatra]

Originally Posted by thinktink

No thank you! A fair number of my plugins rely on them being installed into the same directory as the core ones. This includes, but is not limited to, X-Fade and LiveWire (for DSP stacking.) And there are probably other plugins this little suggestion would break.

probably, but new versions could account for it. seems to me there should be something like the path variable in windows so that exes are available regardless where you are. (speaking analogously).

to put it another way, like I said in my last post, I would think that changes could be made that would attempt to keep the old way active while allowing a new, cleaner way to do things.

[thinktink]

Originally Posted by MrSinatra

probably, but new versions could account for it...

The new versions yes but not the old ones.

Let's take a mental exercise into this proposal:
Take the classic DSP stacker. Let's say the Multiple DSP Stacker. It still get's installed into the original "Plugins" folder. Now let's conjure up a new third party plugins folder IAW your proposal, let's call it "ThirdParty" and put it into either the root of the Winamp install path or even as a subdirectory of the original "Plugins" folder. Now let's invent us up a brand new DSP plugin that is "new third party API aware" called say "TheAmaZingThingaMaDSP" and install it into the new folder.

With this setup now implemented the popular "Multiple DSP Stacker" won't be able to find the new fangled "TheAmaZingThingaMaDSP" to be able to stack it because it's 1) not aware of the new API 2) doesn't know about the new install folder to search in it to find the new DSP.

This will be true for any plugin that either hooks, chains, or otherwise directly fondles other plugins. There is no API mechanism for direct inter-plugin communication or awareness, therefore any changes of any kind to the storage mechanism of plugins that developers originally expected to deal with when the plugin was originally created will break various plugin's original intended functionality, rendering them (at least partially) impotent. In this example, the "Multiple DSP Stacker" won't be able to stack "TheAmaZingThingaMaDSP".

[DrO]

which is why i'm not bothering with it as on thinking it through (before i'd seen the above), it completely screws up any 3rd party assumptions which is bad. also it doesn't work reliably with 1st party without a load of extra work. was a nice idea but not going to happen.

[Koopa]

thinktink:

I wanted to test your plugin and installed it with your installer, the installer placed a 'opusfile' folder with 3 dll files and a readme in Winamp's root dir and the "in_bpopus.dll" and "enc_bpopus.dll" in Winamp's plugin dir.

The problem is, that my Winamp doesn't start when the plugin is in the plugin folder, any idea? As soon as i delete in_bpopus.dll Winamp is starting again. "enc_bpopus" is just working fine.

You can catch all infos from my Winamp Info Report in my signature.

[thinktink]

Originally Posted by Koopa

thinktink:

I wanted to test your plugin...

I sent you a PM with one thought.

Here is another:
Maybe it's a conflict with one of the other third party plugins. Might be a good idea to zip all those up and post it somewhere for me to download and maybe I can see which one.

[MrX_1980]

Happy easter!
I have tried today the Opus encoder (rip all/selected tracks from audio cd) but I get always the message "Error ripping track #1: Cannot open encoder"
I have used your installer (1.1.13.30) and the opus encoder default values.
I also tried "run Winamp as admin" (Win7 x64 Ultimate SP1).

What could be the reason ?

[Koopa]

Originally Posted by thinktink

I sent you a PM with one thought.

Here is another:
Maybe it's a conflict with one of the other third party plugins. Might be a good idea to zip all those up and post it somewhere for me to download and maybe I can see which one.

I've 7-zipped all of my 3rd party plugins and sent you the link via PM.

Also with latest internal build I have the same problem. Even tried without language pack, and with a classic skin, but same effect.

[thinktink]

@MrX_1980: CD's are 44.1KHz and that's not one of the support input sample rates of the encoder plugin (hopefully yet) as I noted in my post.

@Koopa: It's a conflict with in_gsf.dll I was able to get crash even with classic skin just as you described. I'm gonna try experimenting different build settings to see if I can get it to clear up. I doubt it.

[Koopa]

Originally Posted by thinktink

@Koopa: It's a conflict with in_gsf.dll I was able to get crash even with classic skin just as you described. I'm gonna try experimenting different build settings to see if I can get it to clear up. I doubt it.

I can confirm it, when in_gsf.dll isn't present, Winamp starts.

[MrSinatra]

sorry I took your thread offtopic TT!

Originally Posted by Kaminari

ALAC is already supported by in_mp4 when Winamp Essentials is installed. Just add the ALAC extension to your in_mp4 settings and you're good to go. (Whoever decided to use M4A as the official extension of the Apple lossless format is a moron.)

Originally Posted by kzuse

Or if your alac files are called .m4a, it works right out of the box, does it?

Originally Posted by Kaminari

Sure. Though many ALAC files outside of the iTunes microcosm use the ".alac" extension.

The only reason why Apple adopted the ".m4a" extension is because the ALAC codec, which is not related to MPEG-4 at all, is nevertheless muxed in a MP4 container. However many MP4 players can't decode the ALAC codec.

Winamp Essentials

ok, so I made a thread for this and I hope you guys will check it out:

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

I am not sure how to do what you are saying so any help would be great.

[MrSinatra]

Originally Posted by thinktink

The new versions yes but not the old ones.

Let's take a mental exercise into this proposal:
Take the classic DSP stacker. Let's say the Multiple DSP Stacker. It still get's installed into the original "Plugins" folder. Now let's conjure up a new third party plugins folder IAW your proposal, let's call it "ThirdParty" and put it into either the root of the Winamp install path or even as a subdirectory of the original "Plugins" folder. Now let's invent us up a brand new DSP plugin that is "new third party API aware" called say "TheAmaZingThingaMaDSP" and install it into the new folder.

With this setup now implemented the popular "Multiple DSP Stacker" won't be able to find the new fangled "TheAmaZingThingaMaDSP" to be able to stack it because it's 1) not aware of the new API 2) doesn't know about the new install folder to search in it to find the new DSP.

This will be true for any plugin that either hooks, chains, or otherwise directly fondles other plugins. There is no API mechanism for direct inter-plugin communication or awareness, therefore any changes of any kind to the storage mechanism of plugins that developers originally expected to deal with when the plugin was originally created will break various plugin's original intended functionality, rendering them (at least partially) impotent. In this example, the "Multiple DSP Stacker" won't be able to stack "TheAmaZingThingaMaDSP".

Originally Posted by DrO

which is why i'm not bothering with it as on thinking it through (before i'd seen the above), it completely screws up any 3rd party assumptions which is bad. also it doesn't work reliably with 1st party without a load of extra work. was a nice idea but not going to happen.

ok... so, I am either explaining myself poorly or i'm just totally wrong, and as i'm not a dev you guys would know better than me.

however, I think you might misunderstand what I am saying.

I am NOT asking that any current functionality be removed or discontinued. I am saying that a "new layer" or approach be ADDED to existing functionality.

now, I understand your point that simply moving the plugins into different, yet more sensible, folders will break many plugins absent any code changes to account for it, (code changes to both the API and the plugins). that's def a valid point.

but what I am saying is it is worth it to do that, if two things are viable:

1. the new system actually works, and sensible folder organization is achieved, itself a worthy goal.
2. legacy functionality is maintained, by simply moving (or keeping) all the legacy plugins manually back to their (current) locations.

if no one cares about plugins, as is often said here, making such a change going forward shouldn't be hard adoption wise, and having a legacy way back shouldn't make it too painful for the hardcore.

I happen to think it would be a good thing to actually make such a change, so that there was a clear line of demarcation between "current" plugins and legacy ones, as well as "official" or stock, and 3rd party.

now I may be approaching differing issues here in a non-optimal way, or I may be wrong about what is or isn't possible in coding/capability terms. but I can see a lot of benefits from this, like a pref for allowing legacy plugins or not, or 3rd party plugins or not, etc, based solely on their location. I also think it would be good to see what plugins are being actively developed still vs which ones aren't. jmho, I don't want to upset anyone!

anyway, again, sorry to pull your thread off topic TT!