Author Topic: Feedback and improvements ideas.  (Read 1248 times)

Beezmann

  • Newbie
  • *
  • Posts: 14
As a regular user with a big library, I've run into quite a few minor issues while using MusicBee for media organization. Nothing bad, just ideas for improvement and quite possibly some ignorance of the program's more advanced features on my part. I'll post some of it in hopes that at least some of my feedback could be useful .

• The most fantastic addition for me would be the ability to modify middle click search behavior to include partial results (via a quick setting, preferably bindable to a key). That is, with that setting on, MMB-clicking on "Bon Jovi" would also display artist results for "Jon Bon Jovi", "Bon Jovi & Richie Sambora" and so on. Ideally, I'd prefer it to be an easily accessible setting bindable to a key for easy switching between strict and loose search results.

• This one might be ignorance on my part, but nevertheless. I'd really love to see boolean operators in the regular Search Box. Yes, I know about Custom Search and use it all the time, but having at least the basic AND/OR/NOT boolean operators in the search box would simplify and speed up things considerably. I'm sure I don't have to explain the concept to the devs, but here are some search examples to illustrate the idea:

Aerosmith && title:(live)
artist:"George Michael" || artist:Wham
artist:<"George Michael" || Wham>
artist:Yes !!Hayes
Elvis !!Presley

And so on. I'm using double "!" "&" and "|" here since single ones may conflict with file names and double ones are extremely likely, but there are more intuitive approaches to this, like toggling the behavior via a dropdown setting "Use boolean operators" and using backslashes to identify non-boolean character searches (i.e., !=logical NOT, \!=exclamation mark) when that setting is on.

• I'd also like the opportunity to be able to directly edit more displayed fields via double click. That includes fields like Time (to quickly correct VBR MP3s's buggy lengths), Track Gain, and Filename. Track Gain in particular is an extremely annoying one, as not only I can't mass edit multiple values, but I have to look for each in the Tag Editor manually every single time I want to tweak it myself. If there's a fear that basic users may misuse this feature to set the wrong length or name for a file, it could be toggled as an "Allow advanced field editing" option in General or someplace else.

That's it for the big ones. Other minor quality-of-life suggestions include:

• A search box in Set Displayed Fields (to reduce unnecessary scrolling)
• Alternatively, Pin to Favorites in Set Displayed Fields (and add a Favorites section on the top of Common Fields and Other Fields)
• The Auto Prevent Clipping option in the Analyze Volume window. Since it already warns about potential clipping, it may as well adjust the value itself.
• Toggleable duplicates highlighting in the main browser. Either the same highlight color or a minor hue shift for each consequent duplicate pair.
• An Ignore List in the Duplicate Manager (e.g., ignoring " (remastered)" would treat "Song" and "Song (remastered)" as duplicates)

These are the most immediate and urgent suggestions that come to mind after years of usage. I hope you'll find any of them useful, and thank you very much for continuing development of this invaluable tool.

Beezmann

  • Newbie
  • *
  • Posts: 14
Regarding the booleans, turns out there was some ignorance on my part after all. After posting this, I decided to take a look at the updated documentation (haven't done it in years) and saw that one boolean operator is already there. Although, after a few quick tests I can understand how I managed to miss it. It's OR (or +), and there seems to be some limitations around its use. Here's some examples of test search phrases that worked and didn't:

WORK:
artist:aerosmith OR title:always
aerosmith OR bon jovi

DON'T WORK:
"aerosmith" OR "bon jovi"
all or nothing OR Black or White
all or nothing + Black or White
"all or nothing" OR "Black or White"

I'd play with it some more, but I decided to post a follow-up immediately to save other posters' time on potential replies.

Oh and while I'm here, here's more details regarding my middle-click search suggestion: perhaps SHIFT+Middle Click could be used for loose (partial match) searches, as opposed to regular Middle Click for strict ones that is used now. Changing it via Hotkeys would be ideal.  Furthermore, I don't know if it's possible to set up strict searches in the search box (i.e., lines like artist:"Bon Jovi" somehow not listing Jon Bon Jovi), but for loose results, it would probably be a good idea to automatically enter the middle-click search term in the search box. So if you SHIFT-middle-clicked Bon Jovi, the search bar would update with "artist:Bon Jovi" (without the quotes), and you'd be able to modify the search on the fly, instead of starting a new one.

Zak

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 2450
• This one might be ignorance on my part, but nevertheless. I'd really love to see boolean operators in the regular Search Box.

Aerosmith && title:(live)
artist:"George Michael" || artist:Wham
artist:<"George Michael" || Wham>
artist:Yes !!Hayes
Elvis !!Presley

The Search box already supports simple and/or boolean operator keywords.
You have to specify the field for each search term though.
e.g.
artist:Aerosmith title:(live)   (Note that an and keyword doesn't seem to be supported, but if you specify multiple search terms it is implied)

The or operator is exactly that - the word itself spelled out:
artist:"George Michael" or artist:Wham

Quoted strings also affect how search tokens are parsed.
artist:John W appears to be parsed as Artist contains "John" and Artist contains "W" and will match both John Williams and Olivia Newton-John.
artist:"John W" appears to be parsed as Artist contains "John W" will match John Williams but not Olivia Newton-John.

I can't find any implementation of a not operator.

And so on. I'm using double "!" "&" and "|" here since single ones may conflict with file names and double ones are extremely likely, but there are more intuitive approaches to this, like toggling the behavior via a dropdown setting "Use boolean operators" and using backslashes to identify non-boolean character searches (i.e., !=logical NOT, \!=exclamation mark) when that setting is on.
That is not very intuitive. I'm not saying there isn't some value in making searches a bit more flexible, but implementing it using "secret" codes means it will never be used by 99.9% of MusicBee users which limits its usefulness.

I've also never seen the role of the Search box as narrowing down the list of displayed tracks to only the four or five specific ones out of 10,000 you want to work with. If your tracks are tagged correctly, simple searches should already let you filter your library down enough that if the four or five tracks you want appear in a list of 10 or 20, isn't that good enough? I'm testing on a library with 50,000 tracks and I'm struggling to find of a use case in which two or three search terms aren't sufficient to find any specific track that comes to mind.
If you find you're getting too many hits, remember you can also specify which fields are searched to only include those that are most relevant. Then you might not need to specify them in the Search box terms at all.

• I'd also like the opportunity to be able to directly edit more displayed fields via double click. That includes fields like Time (to quickly correct VBR MP3s's buggy lengths), Track Gain, and Filename.
Editing the track duration is almost certainly never going to be implemented as it's a derived value based on the file properties. If you have VBR files with dodgy headers, the solution is to fix the headers, not fudge the length of the track. If you have so many that it's an issue, you might look into adding an external application link to something like mp3val and sending your files to that to fix them.

Finally, that's a long list, and there is only one dev - singular - who maintains MusicBee in his spare time. So given how specific some of these requests are, you might need to keep low expectations about them being implemented in the near future and look for other workarounds.
Bee excellent to each other...

Beezmann

  • Newbie
  • *
  • Posts: 14
Hey Zak, thanks for your reply. Sorry I made you type the boolean stuff, though. I tried to post an update as fast as I could but it clearly wasn't fast enough. I should have looked at the updated documentation before posting anyway, so my apologies.

Regarding the intuitiveness of the operators, as you can see from the examples in my second post, it's already an issue. Searching for "all or nothing"  and "Black or White" (without quotes) gave me the results for "all", "nothing", "black", and "white". Searching for them with quotes gave me no results at all. I suggested backslashes since that's what everyone does (REGEX also uses them), so I doubt that many advanced users would have a problem with it, but I definitely agree that double "!!", "&&" and so on are dumb. I just used them for illustration purposes to simplify my examples.

It's hard to say what the best approach would be, but with your concerns, I'd probably suggest a combination of grouping via quotes (or <>) and strict capitalization rules for the operators. So, "or" is a search term, but "OR" is an operator. AND, as usual, could be omitted. So:

"Tito & Tarantula" OR "Tito and Tarantula"
"all or nothing" OR "Black or White" 
(would look for exact "all or nothing" or exact "black or white", no partial matches)

"Tito & Tarantula" AND "Dust And Ashes"
"Tito & Tarantula" "Dust and Ashes"
(would narrow the results to both "Tito & Tarantula" and "Dust and Ashes", exactly. Boolean AND can be omitted with the quotes.)

all or nothing
(would act as a regular search for "all" "or" and "nothing")

all OR nothing
(would search for "all" or "nothing")

And so on. To quickly address the rest of your post, I didn't realize that changing the track duration field was that complicated, so we can just forget about it then (where's that edit button?). Directly editing the Track Gain value, however, would definitely be one of the biggest items on my wish list, especially since it's probably the easiest to implement–by far. And as for my expectations, I have none. Although I didn't expect it to be a single developer (wow!), I only listed this stuff in hopes that some of it could be seen as useful suggestions. I've been happily using MusicBee for years without all this and I'll continue to do so at any rate.

Zak

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 2450
Hey Zak, thanks for your reply. Sorry I made you type the boolean stuff, though. I tried to post an update as fast as I could but it clearly wasn't fast enough. I should have looked at the updated documentation before posting anyway, so my apologies.
All good. It gave me a chance to brush on the search box keywords. And I could have searched the documentation too, but decided it would be more enlightening to wing it.

Regarding the intuitiveness of the operators, as you can see from the examples in my second post, it's already an issue.
It's only an issue if you regularly perform searches like this on a massive data set that returns too many false positives for what you're actually trying to achieve.
Don't get side-tracked trying to find perfectly parseable search terms - outing yourself as a developer at the same time - and overlooking what will already work, at least good enough if not perfectly.

"Tito & Tarantula" AND "Dust And Ashes"
"Tito & Tarantula" "Dust and Ashes"
(would narrow the results to both "Tito & Tarantula" and "Dust and Ashes", exactly. Boolean AND can be omitted with the quotes.)
As search terms are inclusive by default, this shouldn't really be an issue.
If you want to find the track "Dust and Ashes" by either "Tito and Tarantula" or "Tito & Tarantula", just search for Tito Tarantula Dust Ashes.
I can't see how that could possibly return any false positives however large your library is. Obviously, that's one specific example, but I'm still struggling to think of any (all inclusive) search that doesn't already work if you specify enough search terms (or partial terms).

Searching for "all or nothing"  and "Black or White" (without quotes) gave me the results for "all", "nothing", "black", and "white". Searching for them with quotes gave me no results at all.
Yep, searching for the word "or" within a tag is problematic. Given that quotes are already supported and the or keyword is already supported, I would consider the fact that they can't be used together like this is a bug, not a missing feature.

From memory, the support for operators in the Search Box was added a long time ago and not really discussed since, which suggests most people aren't trying to use it for anything too complex. It could be revisited to make it more robust. No idea how it was first implemented, but I imagine there are third party libraries available that handle this kind of thing.

Directly editing the Track Gain value, however, would definitely be one of the biggest items on my wish list, especially since it's probably the easiest to implement–by far.
It sounds like you're talking about editing values as provided by enabling Enable direct editing of tags in the main panel, and it does seem arbitrary which fields can be edited in the main view and which ones can't. Being able to edit the file name this way seems like it should be supported.

This still wouldn't let you edit a tag value for multiple files at once though. You could try using the Tag Inspector for that. I can't actually see how to access that via the GUI, but you can assign it a keyboard shortcut.
Bee excellent to each other...

hiccup

  • Sr. Member
  • ****
  • Posts: 7790
Directly editing the Track Gain value, however, would definitely be one of the biggest items on my wish list, especially since it's probably the easiest to implement–by far.
It's easy indeed:
Just create a custom tag with 'replaygain_track_gain' as the tag code for id3 and vorbis.

Beezmann

  • Newbie
  • *
  • Posts: 14
Thanks again for your replies. Here are a few notes:

Replay Gain
Hiccup, thanks for the tip, but my recurring issue is not creating the replaygain_track_gain tag but quickly adjusting the values of existing ones. I already have Tag Inspector on shortcut, but it's still a major PITA to use repeatedly since you must scroll down and manually search for replaygain_track_gain for every single file. The value is displayed right there in the main browser and could easily be made editable just the way other tag fields are. I just don't see any potential downsides to this, and it seems piss-easy to implement.


Booleans:
The "Tito & Tarantula" "Dust and Ashes" example above was bad since that exact type of search already works (without AND), but my point was that the quotes (which indeed are already implemented for regular searches–sorry for ambiguous phrasing) don't seem to work when used with boolean operators like OR. As for false positives, that a weird thing to say about a handful of very basic illustrative examples. Obviously, who'd need any advanced features to look for Tito & Tarantula's Dust and Ashes? My own searches are far more specific and error prone, and I mostly use them not to search for music but to organize my incredibly messy library into usable shape (standardizing names and whatnot). If you need real life examples, here's a few:

"ft " OR "feat " OR featuring NOT defeat
"ft." NOT "ft. "                                                      (to filter for badly tagged names like "Shaggy ft.Sting")
"live" NOT "(live)"
"  " OR ") ("

Etc. Plenty of opportunities for false positives without the quotes and operators, as you can see. If this ever gets revisited, I really think that differentiating between capitalized operator OR and regular "or" is the best way to go. The search box is not case sensitive anyway, so there's no possibility that somebody would need a specific search for "OR" and not "or" anyway. Another thing to add is that the NOT operator is arguably even more needed than OR, since it would really allow to quickly narrow the results without ever going to Custom Search ("Michael Jackson" NOT "Jackson 5"; feat NOT defeat; etc.)


As a final note, all this discussion would largely be redundant if you could just dock Custom Search as a side panel or a persistent floating window, instead of it being an overlaying popup that completely blocks the use of the main browser when opened and automatically closes after every single search. Perhaps that's the one suggestion worth going with. Would that be difficult to implement, do you think?




hiccup

  • Sr. Member
  • ****
  • Posts: 7790
…my recurring issue is not creating the replaygain_track_gain tag but quickly adjusting the values of existing ones., and it seems piss-easy to implement.
It's usually frowned upon when a user says that something is piss-easy to implement for a developer.

Also, you don't seem to understand how custom tags work.
Just try my suggestion, it's really piss-simple.

Beezmann

  • Newbie
  • *
  • Posts: 14
…my recurring issue is not creating the replaygain_track_gain tag but quickly adjusting the values of existing ones., and it seems piss-easy to implement.
It's usually frowned upon when a user says that something is piss-easy to implement for a developer.

Also, you don't seem to understand how custom tags work.
Just try my suggestion, it's really piss-simple.

I'm a developer myself, and from my perspective it does seem piss-easy when you consider that the program already routinely does pretty much the exact same thing for other tag fields. It's like saying that adding a keyboard shortcut for Rating:Ban would be piss-easy because, in fact, it would be. If I'm mistaken and there's somehow an extra challenge involved, you are more than free to just state so. No need to get offended, especially if you have nothing to do with development yourself.

As for your suggestion, perhaps you could rephrase it? Because the way I understood it, you gave a tip how to manually create a tag and not how to edit its value inside MusicBee any faster, and that has nothing to do with anything I said whatsoever. Take it easy, friend.
Last Edit: May 11, 2022, 07:23:12 PM by Beezmann

hiccup

  • Sr. Member
  • ****
  • Posts: 7790
As for your suggestion, perhaps you could rephrase it? Because the way I understood it, you gave a tip how to manually create a tag and not how to edit its value inside MusicBee any faster, and that has nothing to do with anything I said whatsoever. Take it easy, friend.
I'm not gonna rephrase it.
A developer such as yourself should easily be able to figure out how custom tags work without somebody guiding you and holding your hand.
If you are not able to figure out it's workings by trying it out yourself, or searching the vast amount of existing forum posts and/or the wiki, feel free to start a new topic in 'Questions'.
I'll be happy to help there.

This 'Wishlist' board is intended for, and most effective when a user proposes a single new feature. Preferably in a concise manner.
This specific thread is nothing like that, and I feel it should be moved, split or whatever.
Last Edit: May 11, 2022, 08:10:07 PM by hiccup

Beezmann

  • Newbie
  • *
  • Posts: 14
As for your suggestion, perhaps you could rephrase it? Because the way I understood it, you gave a tip how to manually create a tag and not how to edit its value inside MusicBee any faster, and that has nothing to do with anything I said whatsoever. Take it easy, friend.
I'm not gonna rephrase it...

So instead of expanding on your own advice, supporting your own suggestion that making the Track Gain field editable would require any significant challenge on the dev's part, of adding anything of value generally, you choose to spend your paragraphs to just troll a new user into submission and waste everyone's time by decrying one irrelevant part of their phrasing? To each his own, I guess. I'm not at all convinced that this is "what this 'Wishlist' board is intended for", but hey, you're the expert.

Anyway, to make it easier for everyone, I'll apologize to you, the dev, the world, and anyone listening, and admit that it would probably not be "piss-easy" to implement for you, me, and potentially even MusicBee's highly experienced dev. And if it's all some payback my not worshiping your feedback from the get-go, I'll apologize yet once again. My coding experience has nothing to with audio tags, and it's quite possible I didn't understand the true brilliance behind your succinct single-sentence suggestion and still don't. Again, if it's a major time saver for the scenario I described, I'll be more than happy to hear more about this, no sarcasm intended. Otherwise, I have no intention to waste my first forum posts on an inane internet argument with an annoyed 6000-post junkie. I say we end it on your inevitable reply and move on with our lives. Thanks again for your initial input.

hiccup

  • Sr. Member
  • ****
  • Posts: 7790
You're funny. (but also a little bit emotional)
Using bingo words such as 'offended' and 'trolling' won't make you gain much respect here.

And calling another forum member a junkie because he has been involved and contributing a lot over a long period of time?
The developer of Musicbee has +30k posts on his name.
So he's a junkie too?

I'm not sure how old you are, but your responses to helpful criticism are very childish.