Topics

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

4

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.

5

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.

6

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.