Latest WACUP beta release is build #9478 (November 30th 2021) | Latest WACUP public preview is build #7236 (March 11th 2021)

NOTE: New beta testers are not currently being added as I need to re-work the beta test program

If you've not already requested to be a beta tester & would like to then please send a PM to 'dro' to be added to the beta test group.

Note: requests to be a beta tester are processed in batches when new beta builds are released so please by patient of this process.

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 - araxhiel

Pages: [1]
General Discussion / It is possible to do queries to WACUP database?
« on: August 10, 2021, 04:09:36 AM »

As title says, I have been wondering for a while if there's a way to do some direct queries to WACUP's database and be able to extract some data and use it externally.

My current scenario is that, after a couple of years where I was mostly using Spotify (you know, to have something to listen to on my work place) I have created a good deal of different playlists that only exists on that platform. So, I want to be able to locally "recreate" some playlists that I have over Spotify, but with the files already on my media library (as most of the playlists that I want to recreate are reproducible using my local files).

So... I have already developed something to retrieve all my Spotify data, and whatnot, but now that I am facing the issue of scanning/reading all my local library in order to be able to recreate those playlists using my local files, and that's where the main question takes relevance:

As I already "have" something that already contains all my library's data, I was thinking into not reinventing the wheel and reuse that already available data source.

I was somewhat aware since the old Winamp days there were a couple of projects that were able to read Winamp's database (I was a lurker at old Winamp forums - lol), and, actually, after digging a little bit I was able to found some stuff from back then (some java, and javascript stuff), but being honest, it is pretty old stuff and 1) I don't know if that stuff worked to begin with, 2) don't know how different is the current database format compared with the old one.

Yeah, I'm probably being very, very lazy (ha!), and perhaps I should look at other solutions, but I though that it was worth to ask and see if it is possible to achieve (I mean... I think that it would be cool to have everything integrated, to be honest).

Any comments, suggestion, or advice is welcome.

Thanks in advance.

Kind regards.

P.S. Sorry for all the grammar mistakes that are present.

Hi all,

Thank you both for the replies.

As the title says there is, there is.
However you seem to be mixing a statement with a question.

Damn :(

Yeah... I must admit that from time to time I had some grammar issues here and there... I'm trying to be more conscious about them, but as we can see, I need to do a better effort. I really appreciate that you have pointed out that mistake.

But, yeah, it was supposed to be a question.

Me I opt for a large high quality image in the folder with the name cover.* or front.* or folder.* or the album name, and if I embed them I use medium sized images usually over 512x512 saved as JPG so they don't bloat the music files too much.

600x600 is what I try to use in the live cached versions as that's a decent trade-off between the decoded memory size & how long it takes to render & how large things tend to be sized to on display without loosing any obvious graphic detail.

Being honest, both approaches are quite similar to I had in mind (but wasn't so sure about it) as I was thinking something like 500x500 images, so it's good to know that I was going into the right direction (for saying something). One thing that I was not taking into account was the format (e.g. PNG vs JPG), thanks for reminding me about that detail.

Once again, thanks for the replies.

Kind regards.


Well, as title says, there is an optimal file size, and/or image size for album art? Performace-wise speaking.

I ask this because I am a heavy user of the Album Art pane, and from time to time I notice that some images take a little bit more of time to be displayed/loaded when navigating through my collection, while few more take more than time to be displayed...

I'm already aware that, according to another post (,776.msg4886.html#msg4886), there are a lot of factor to keep in mind regarding how images are handled, but still I was wondering if there is something like a "sweet spot" for image "specifications", or even configurations.

For example, ignoring the fact (for the moment) that most album art are quite different from each other (small, big, PNGs, or JPGs), I tend to embed the image on the audio file, but not quite sure if that means that WACUP will do an additional effort/require more resources than if I use the "folder.jpg" file that is inside each folder.... Or vice versa.

Also, additional to that, is the fact that I have used a very, ahem, diverse set of images ranging from JPGs, 250x250, and a few kb of size, to a couple of images that are 2000x2000 (if not bigger), with a size of 1, or 2 Mb (can't recall right now)... So, I'm thinking that also achieving some consistency would help.

Thanks in advance.

I think the OP is looking more for
Release Country
Release Status
Release Type

Hi! Yes, those are the tags that I had in mind as they could be more standard rather using the ones from MusicBrainz or Discogs.

Sorry for the very late response, btw.

As the title says, it could be a great feature to have more flexibility while creating/configuring a Smart View, based on other tags besides the ones that the application already uses.

To give more context, I'll provide my particular scenario:

Currently, in order to keep my collection organized I rely a lot on the use of Smart Views, where I can filter the albums/artists by music genre, release type (LP, EP, Single, Split), "album type" (Studio, Live Album, Demo, Compilation, etc.), Country/Region (Germany, Norway, U.S.A., etc.), among other "categories".

So far, I've managed to do this using some of the default tags, such as genre, length, filename, and comment, being this one where I set most of the values that I want to use to filter the songs/albums on the Smart Views (ie. Comment = "Germany, Single" or "Spain, Live Album") using the "contains" operator in order to achieve my goal.

But, at least with some of the filters that I use there are already available tags for that information, like "Media type" that can be used instead "comment". Also, there are private frames that can be designated for other type of data that hasn't a proper tag field (like "country", or the ones that iTunes uses, or MP3Tag uses when downloading information from discogs).

So, it could be possible/feasible to add some compatibility with additional tags that aren't available on the default Smart View configuration? (both existing, and user defined)

Thanks in advance.

Pages: [1]