Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - dro

Pages: [1] 2 3 ... 32
Wishlist / Feature Requests / Re: EBU R128 loudness normalisation
« on: June 06, 2019, 07:55:49 PM »
I've made a quick experiment (having hacked up the waveform seeker plug-in as that's using the same method but its simpler to just get running than the replaygain action) & doing as close as I can get for a like-for-like between MP3 & FLAC versions of the same file (~90mins), MP3 decoding takes ~21s vs FLAC decoding takes ~11s.

Again it's still apples vs pears due to format & decoding differences but I am more likely to lean on the relative slowness being down to current in_mp3 from 5.666 7 the FhG decoder library rather than the transcoding API in this instance.

The next test (but not for now as I need to finish off getting a new beta & preview build out this month) will be seeing what the decoding speed is like when using a different MP3 decoder which luckily can be done without a replacement in_mp3 since I've got control over the transcoding api so can make it look at a non plug-in instance instead, muwhahaha :)


Wishlist / Feature Requests / Re: EBU R128 loudness normalisation
« on: June 06, 2019, 01:48:47 PM »
It's somewhat of an apples & pears comparison as they're using different decoder engines (Fraunhofer's official library vs FFmpeg's) & I know that the FhG instance has issues with handling some seek tables so it's possibly something to do with that (i.e. it goes into slow mode vs using the appropriate mode) or there's locks within the decoding that are hindering the overall throughput of the decoding process (which isn't an issue for normal playback) or its on the other side of the fence & dealing with the data once provided by the input plug-in.

Until I start digging it's hard to know & whether there's an easy 'fix' or if it's more a fundamental aspect of what's being used. If it's in_mp3 & the FhG library then it just gives another reason to look at moving to a different plug-in than relying upon it (since it's a beast already).


Wishlist / Feature Requests / Re: EBU R128 loudness normalisation
« on: June 05, 2019, 10:40:22 PM »
Ok, I'll see if there's anything obvious from my side that's wrong / causing a slow down but I've a feeling its more likely the mp3 decoding library being used that's causing the bottle-neck in this instance. I should probably also have a look at some of the other formats like FLAC to see how they might also compare.


Wishlist / Feature Requests / Re: EBU R128 loudness normalisation
« on: June 05, 2019, 10:33:00 PM »
Are they MP3 files by any chance? As getting the audio data is dependent upon the input plug-in responsible though I've not looked too much into the speed of data acquisition as having it work was more the priority but I'll have to do some testing it seems.


Preview Build Discussion / Re: Waveform Seeker Negative-Function
« on: June 05, 2019, 10:28:43 PM »
People seem to be using it as a bit of both depending on the skin or needs at the time :)


Wishlist / Feature Requests / Re: EBU R128 loudness normalisation
« on: June 05, 2019, 10:16:53 PM »
Parshift: It'll primarily be because it's doing the processing a file at a time instead of multiple files at the same time. When I first got the feature re-implemented, I only did the single file at a time method just to help verify that the processing was correct & not causing issues (which it did for a bit until that was resolved).

I've not come back around to working on the plug-in to finish off the multiple file processing which is why we've got the slow but stable approach still. It will hopefully get some love later this year to bring it up to the expected level of processing multiple files.

Thus, I strongly recommend allowing Replay Gain to be edited, and to at least be open-minded about alternate loudness measures.
I thought I had been open minded in providing the 2 common methods that other players are using so a) I maintain compatibility for those needing it whilst b) adopting what from my research has been deemed the more appropriate solution to use. If there are other options that a decent majority are using then I'm open to trying to add support for them, subject to code & licensing related to it.

With regards to manually editing of the values, its not been done yet as not all of the input plug-ins that are responsible for handling such matters have been replaced &/or modified to make it viable to generically edit that metadata. Once that's done then the singular & batch edit dialogs will get the support added to them.

I know most just see it is disabled edit controls but to have things done consistently (which has been an issue with Winamp not doing that) then there's a few pieces that need to be sorted out which is part of my end goals to have key tagging functionality somewhat isolated from the input plug-ins so things can be done to it without having to update half a dozen plug-ins &/or the duplicated code that comes from some of them using the same tagging format (e.g. ogg vorbis + flac plug-ins).


Wishlist / Feature Requests / Re: Flac Support over Icecast
« on: June 05, 2019, 08:44:35 PM »
MourningStar: I've never kept it secret that it's predominantly just myself working on WACUP though others have contributed (largely in some cases) from providing existing plug-ins to be integrated through to whole new skins & general motivation / testing / kicks up the arse from time to time.

The vast majority of media players out there are typically developed & maintained by at most a handful of people so its nothing abnormal in that regards though it essentially being my job probably is but that's a whole different can of worms.

And is what Dr.Flay is referring to :)


Wishlist / Feature Requests / Re: Flac Support over Icecast
« on: June 03, 2019, 01:18:12 PM »
Winamp/WACUP's streaming support is one of the bigger tasks that still needs re-working especially to aid in not having to manually add extensions to the urls to get the correct input plug-in to work. Without doing that, it's generally the mp3 input plug-in which gets the stream which doesn't then hand it off to the ogg vorbis plug-in when it came to the other stream you mentioned.

So for an Icecast + FLAC stream to work, I need to add support for Ogg+FLAC streams which I'm still debating how best I want to do it since there's also Opus which uses the Ogg container & making one plug-in (or a mini service) that can deal with all 3 would make life much easier going forward (along with boosting the out of the box support that WACUP could offer).

Its already something that's been on my todo list but as Ogg+FLAC streams aren't all that common I've not bumped it up the todo list but will see what happens over the next few months.


I'm only seeing an image of the main window & not the desktop - if some of it is showing then you should be able to click & move it as long as "easy move" is enabled. Alternatively you need to edit the mw_xpos & mw_ypos values in gen_ml.ini in the settings folder (Preferences -> Advanced -> Diagnostics -> 'Settings Locations' shows the file path of gen_ml under the 'Library Settings File' part so you don't have to guess what's going on.


Wishlist / Feature Requests / Re: Send to External tool
« on: May 22, 2019, 12:04:50 PM »
It might make sense to do something to make certain actions more integral to what's offered if such tools can be found than relying on the explorer style context menu & hoping that things are in there. The other one that came up on reddit recently relates to mp3tag & I was thinking of adding a dedicated sub-menu for that so maybe if the explorer context menu option is too many levels than I can pursue more specific integration options.

Wishlist / Feature Requests / Re: Send to External tool
« on: May 21, 2019, 09:25:15 PM »
I'm having a look at the explorer context menu request tonight so will see how that goes - hopefully it'll make it into the delayed next beta build.


General Discussion / Re: Bookmarks
« on: May 11, 2019, 09:45:50 PM »
If you've not categorised any bookmarks (which under 5.666 required manually installing a plug-in from me) then that's expected. Just mentioned it to clarify what the different files might be & why they're needed :)

General Discussion / Re: Bookmarks
« on: May 11, 2019, 12:26:16 AM »
winamp.bm8 is the main file used (is UTF-8 encoded to better deal with non-english characters) whilst is the legacy file using the machine local for encoding which was being generated to maintain compatibility with very old plug-ins (there's a few other cases like that which later under WACUP I plan on removing being generated by default).

The winamp.bmc file is the categories (if applied) to the bookmarks. I had to do it in a separate file to avoid breaking code assumptions with the layout of the files. so like mark notes, copying all 3 files is a requirement (subject to what exists in the other install) to do a full migration of the bookmarks.

Additionally they're just plain text files so you could depending on your needs copy+paste the contents for the files of one install into the other though that's not going to be work correctly with the bmc file (not unless you adjust the indexes of the copied entries & adjust the reported total catergory size in the file).

I need to look into having a mode that makes it easier to import certain settings from another Winamp/WACUP install. bookmarks, podcast feeds & playlists seem the commonest ones followed by local library & history databases.

General Discussion / Re: Hello and many questions from newbie
« on: May 07, 2019, 03:57:55 PM »
the ipod won't show up as WACUP hasn't touched anything to do with the management of such devices over what Winamp provides & Winamp hasn't supported most of the ipods that were released over the years (was a never ending battle that was halted due to legal ramifications which AOL at the time didn't want). Unless ml_ipod fares better (depends on the model year of ipod but even that's not been touched in years), there's not much a WACUP/Winamp install can do.


p.s. I've removed the other duplicate posts that were made asking this same question in somewhat unrelated threads yesterday.

Skins / Re: Big Bento Modern - final release v1.13
« on: May 03, 2019, 01:44:21 PM »
Ok well if it is an SSD then I'd have expected the classic skin to load quicker than that. Can I ask what age the machine is as SSDs in laptops still aren't a common thing (at least not for what I was looking at over the past year especially when you drop down to the Celeron ranges unless it's been an option &/or changed later on).

There's so many variabes as to what could be going on from A/V software being slow to scan & allow things to go to just something about the machine really not liking things (it happens) through to the network connection being slow for the initial update check (though I've tried to mitigate against that due to delaying when it's done by default so that's probably less likely to be it).

Bit of a head scratcher though not helped that the modern skin engine has always liked fast speedy setups as it does a lot of things in order instead of asynchronously which if there are slowness can make the skin take a lot longer to load than would be liked.


Pages: [1] 2 3 ... 32