Messages

1

MusicBee Wishlist / Editable Track Gain and Album Gain fields

« on: April 13, 2024, 12:31:33 AM »

Hi, can you please make the Track and Album Gain fields directly editable, like the rest of the displayed fields?

I very often have to tweak the automatic ReplayGain values to my liking or remove the existing ones, and that simple feature would simplify my workflow enormously. Since the tag always assumes a decibel value, the editable part can just be numerical (a two-decimal float), with the "dB" part added as a suffix on submit.

Thank you very much.

P.S. Just realized that the Filename field is also uneditable. While not a priority for me, it could be neat to make it editable, too, depending on the amount of work it would take. The sequence there would be to rename the file while simultaneously updating its new path in the database, with no extra steps like file rescanning required. Just some food for thought.

2

MusicBee Wishlist / More font sizes for the Floating Lyrics window

« on: February 10, 2023, 01:45:01 AM »

As a quick quality of life improvement, please consider adding support for larger font sizes in the Floating Lyrics window (+ and - UI buttons). Sometimes you want to quickly enlarge the lyric text for it to be visible from farther away across the room, and (unless I missed a setting) the existing zoom options are extremely limited.

I'd also add the standard zooming shortcuts support  (CTRL-+/- and CTRL-mousescroll) used by most browsers and text editors for both the Floating Lyrics window and the Lyrics panel. So, when the Floating Lyrics window is in focus, CTRL-NumPlus or CTRL-MiddleMouseButtonUp would temporarily increase its font size, and CTRL-NumMinus or CTRL-MMBDown would decrease it (exactly like the +/- UI buttons). If the regular Lyrics panel is in focus, the shortcuts would do the same there but save the new default size in the settings (since it's more likely that people would want to set up and keep the anchored panel's new size as default, rather than zoom it temporarily.)

Another fairly easy improvement to consider Floating Lyrics is the ability to select select and highlight a line (same as clicking an item on the playlist would highlight the whole row), to make following non-synced lyrics manually easier. Keyboard Up/Down arrows to select previous/next line (when the window is in focus). Can be applied to the Lyrics panel as well.

3

Bug Reports / Re: Year field stops being directly editable in Playlist view.

« on: May 20, 2022, 09:28:46 PM »

Pretty sure this is not a bug as it's working fine for me both in the main collection and in a playlist.
Have you enabled Preferences > Tags (2) > tag handling > enable direct editing of tags in the main panel?

Thanks for the quick reply and test. I knew that it might have been an issue with my skin, plugins, and so on, so I downloaded the latest version from the website and ran in through a sandbox before posting. After your "this is weird!" post, I did some additional digging and realized the source of the problem. There are two separate fields, "Year (xxxx)" and "Year". You most likely tested the Year one, since I just checked and it's editable everywhere. I was using using Year in my regular views and Year (xxxx) in the playlist view, and since the fild was sized too small to see the "(xxxx)" part of its description, I didn't realize that I was using two different fields...

Anyway, it appears that "Year (xxxx)" isn't editable at all, most likely by design. I'd still prefer it to be editable since I like to just use years and disregard the days and months, but that's obviously not true for everyone and the editing was likely disabled to prevent accidents. The solution for people like me is to change the non-editable field to the editable one, which I just did.

Thanks again for helping me figure it out as it was driving me nuts. You can just lock the thread and sorry about the confusion.

4

Bug Reports / Year field stops being directly editable in Playlist view.

« on: May 20, 2022, 07:56:38 PM »

The "Year (yyyy)" field stops being directly editable in the Playlist view.

Severity: very low.

Steps to recreate:
1) create a playlist
2) try editing any "Year (yyyy)" field value (at least non-empty one) by either clicking on the value twice or clicking it once and pressing F2. It won't become editable like it usually does.

The reasons why it's likely a bug:
1) The Year field is perfectly editable in other views like Music or Folders.
2) Other editable fields are still editable in the Playlist view, at least the ones I use.
(From what I use, only Title, Artist, and Album are always editable. Other, less common fields may be affected by the same issue as well.)

Tested in 3.5b (3.4.8033 P) and freshly installed 3.4.8033. My apologies if this has already been reported–I haven't found it in my search.

P.S. If you ever decide to address this, please consider making currently uneditable Track Gain and Album Gain fields editable as well while you're at it.

5

MusicBee Wishlist / Re: Improved Search Box search syntax

« on: May 20, 2022, 05:34:43 PM »

Forgot to add, the easiest way to introduce users to the shortcuts (that also applies to the existing ones–I'm sure many users don't know about them) would be in the Set Search Fields popup, via either tooltips (preferable but more work) or a simple field name text edit like this:

6

MusicBee Wishlist / Improved Search Box search syntax

« on: May 20, 2022, 04:50:04 PM »

I already addressed some potential Search Box improvement ideas in my general feedback thread (a much needed boolean NOT operator, etc.), but I believe this one is worth considering as well. The suggestion is to enhance the search box syntax with abbreviated capitalized shorthand alternatives to the regular search modifiers (title:, artist: album:, etc.). E.g.:

genre:Rock  =  G:Rock  =  GE:Rock
albumartist:Aerosmith = AA:Aerosmith
artist:Jovi  title:Always   =   A:Jovi  T:Always    =   AR:Jovi  TI:Always

Rationale: speeding up searches considerably at very low development cost.

Notes: the only development requirement here is an added case check to the search box parser, to differentiate capitalized modifiers like A: from regular searches like "a:". Same idea as my boolean operators suggestion (OR=operator, or=search term "or"). As for the shortcuts themselves, single-letter shortcuts would be ideal, but the problem is that something like A: can stand for both Artist: and Album:. The workaround I'd go with (since I made something similar once and know it works) is to use two-letter abbreviations for all (AR[tist], AL[bum], TI[tle], GE[nre], YE[ar], etc.) and additional single-letter ones that default to the most commonly used fields (A[rtist], T[itle]) or those that only have one field for that letter (B[it depth], [W]ork, Y[ear]). The rule for abbreviating is very intuitive: if it's one word, it's the first two letters; if it's multiple words, it's the first letter of each. So:

title: = TI: = T:
Artist: = AR: = A:
year: = YE: = Y:
Album: = AL:
OriginalAlbum = OA:
AlbumArtist = AA:
Etc.

Potential objection #1: "The average user may get confused", etc. The ever-present "average" user doesn't have to use it, and I highly doubt that even the slowest of the slow won't understand the mechanics behind A: (and AR:) = artist: and AL: = album: .

Potential objection #2: "There are too many similar fields for 2-letter searches! What about Sort Album and Sort Album Artist? We should only use 3 letters or none at all!" I like uniformity in design as well, but not at the cost of speed and functionality. The chances that someone will be searching for Sort Album Artist (can you even search for them by typing now? What is it, SortAlbumArtist:?) are infinitely lower than those for Artist: or Title:. In this particular case, I'd go with SA: for SortAlbum: and SAA: for SortAlbumArtist:. It's not THAT confusing, especially to anyone willing to take a single look at the documentation or even make an educated guess based on the common abbreviation rules they can see from other fields. If Custom1: = C1: and Custom2: = C2, it won't take a genius to figure out that Custom12: = C12: . Besides, you can always go back to using full sortalbumartist: if optional SAA: too hard for you to figure out.

Potential objection #3: "We need new features, not some optional tweaks of the already working ones. Don't waste a single dev's limited resources on a whim!" First, just because you don't need faster searches doesn't mean that no one else does. I'm in the middle of organizing an enormous, badly formatted library, and I use close to a hundred of searches per session–which would translate in enormous time savings with this. More importantly, it's a VERY low cost suggestion. 99% of the code is already there. All that is needed is to literally add support for an uppercase check in the parser (very easy, if it's not there already), add the new keywords to the same parsing function (which is as simple as changing [if "title:"...] to [if "title:" || "T:" || "TI:"...]), and update the documentation page.

7

MusicBee Wishlist / Re: Can the Custom Search window be made non-modal?

« on: May 17, 2022, 05:11:06 PM »

I'm posting it here instead of a new thread, since it seems like a closely related suggestion:

If this ever gets implemented, I'd highly suggest making the Search & Replace window non-modal as well. It would speed up the process of renaming considerably, by allowing to make new searches and selections on the fly, instead of closing  the popup and reopening it. With the way it is now, even if you select the entire library, you still can't scroll through it to review what else needs renaming while the popup is open.

8

MusicBee Wishlist / Re: Feedback and improvements ideas.

« on: May 11, 2022, 08:15:39 PM »

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.

9

MusicBee Wishlist / Re: Feedback and improvements ideas.

« on: May 11, 2022, 07:19:37 PM »

…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.

10

MusicBee Wishlist / Re: Can the Custom Search window be made non-modal?

« on: May 11, 2022, 04:20:30 PM »

I was just musing about the exact same thing in my thread! Here's the quote:

[A]ll this discussion [about logical operators in the search box] 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?

Great minds think alike or what?  It seems like the biggest cost-effective improvement to improved searches to me, so I'd happily see it done. I wonder how difficult it is to implement, and–with MusicBee's single dev already up to his neck in work and requests–whether something like this could be added by a third-party via an addon.

11

MusicBee Wishlist / Re: Feedback and improvements ideas.

« on: May 11, 2022, 03:38:42 PM »

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?

12

MusicBee Wishlist / Re: Feedback and improvements ideas.

« on: May 10, 2022, 09:34:03 PM »

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.

13

MusicBee Wishlist / Re: Feedback and improvements ideas.

« on: May 10, 2022, 08:40:01 PM »

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.

14

MusicBee Wishlist / Feedback and improvements ideas.

« on: May 10, 2022, 06:43:21 PM »

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.

15

Questions / Using spaces in Ignore Words

« on: May 09, 2022, 10:56:57 PM »

Hey guys, really glad to finally be on the forums. I have a long list of suggestions and [very] minor grievances for my favorite audio managing program, so here we go.

On the lastest 3.4 version, Preferences->Sorting/Grouping->Ignore Words doesn't seem to accept spaces (e.g., "Song (remastered)" won'tt sort as "Song" even with " (remastered)" in the ignore list). Is there a way to fix this behavior? I tried quotes and common space symbol codes like %20 or &nbsp; without any success. Am I still missing something? If not, can this be patched in? It's kind of a big one for me, since I mostly use the feature to ignore specific title endings, not beginnings.

As a related idea, perhaps the Ignore Words feature could add quote support for the ignored text, so even commas themselves could be ignored? So, for example, phrases like " (live, MTV Unplugged)" or " (bonus track)" both could be ignored? An alternative to quotes would be switching to a less common separator symbol, say "|" instead of "," .  Not that this affects me as much. My biggest issue is that space problem described above.