Messages

1

General Discussions / Re: Another resource for finding cover art

« on: July 01, 2025, 11:54:03 PM »

But all of the sizes show as unknown.

Go into the options, check "Only when size is unknown" under "Automatically download full-size images".

2

MusicBee Wishlist / Re: make ID3v2.4 the default

« on: March 09, 2025, 10:45:27 PM »

A long time ago in a galaxy not really far away I used to follow Foobar's advice which told me to use id3V2.3 for better compatibility. Being someone cautious, I never reassessed this advice. Then I saw this thread and wondered which kind of compatibility I was searching for. We're in 2025, I don't listen to music on my phone of anything else outside my home, both my wife and me use Windows and I don't share my music so why the hell should I be worried about some potential problem that'll never arise?

So I spent a whole day converting my 2 TB folder, then spent another day to do my local save and another day to do my cloud save. hiccup, please expect my march electricity bill.

3

MusicBee Wishlist / Cover dimensions according to the duration

« on: October 17, 2022, 01:08:03 PM »

Being cover centric, here's something I always wished in my player: displaying the covers according to the 3 main vinyl formats I know of:

- 12", the standard album which would be the "full" cover/thumbnail
- 10" for some extended plays and 40's/50's albums = 83% of the standard album
- 7" for the standard single = 58% of the standard album

I never saw this feature in any player. Maybe for good reasons: most people probably wouldn't care and it may be a nightmare to code. But hey, it doesn't hurt to discuss it.

Years ago, I thought I would do it manually: enlarge the canvas of my singles covers in a photo editor and save them as PNG with transparency. It worked, but when I envisioned the time I would spend on this project, I gave up. The size increase of PNG over JPG was also a deterrent at the time. It's not anymore with huge hard drives/SSDs and I could use a macro or a script to semi-automate it, but still... wouldn't it be cool if it was an option in MB?

Obviously, we're not in the vinyl age anymore and the cover dimensions are not correlated to the record's duration anymore. On CD, an album, a mini-album and a single have the same size (I still have some mini-CDs released in the 80's/90's but the format has pretty much been dead ever since). This wasn't true either before the vinyl: a 78RMP album was simply several 78RPM in a box or a binder. Nonetheless, being old and having grown with vinyl, I 'm still imprinted with this representation: the bigger the record, hence the cover, the more songs on it.

4

MusicBee Wishlist / Re: Alternate grouping view with a "cover" title

« on: August 06, 2022, 09:51:55 PM »

+1, I'd like this.

5

Beyond MusicBee / Re: Roon's community

« on: July 20, 2022, 11:12:39 PM »

I used Foobar for 10 years but tested or retested lots of other players in the meantime (including commercial ones like JRiver Mediacenter) because I wished for a slicker UI without losing all the features I loved. But I always returned to Foobar after a day or two (sometimes an hour).

Roon has indeed tempted me with its very, very nice UI screenshots but I was pretty sure i'd find it mostly gloss without filling my needs. The high price was a bad point, too, considering I don't need multi-room features, and I loathe the subscription business model for local software. So... I never got to test it.

Anyway, I eventually tested MB some years ago and I've been happy as I can be ever since. I'm still open to new experiences, though, but in this new era of streaming music and platforms proprietary players, I doubt I'll see something better suited to my needs than MB. Beautiful UI, a lot of customization possibilities, perfect to manage a huge local library: my search is pretty much over.

6

MusicBee Wishlist / Re: support for non-audio files such as documents and images

« on: July 03, 2022, 01:19:01 AM »

The metadata would be there to make full use of.
It would 'live' in the database/library file.
(...)
Sure there are dedicated programs for managing videos, ebooks, documents, images.
They all have their own strong points, but they also have their weaknesses and limitations.

But every kind of document has specific tags that don't exist in audio tags.  Right now, images and PDF are associated to audio files in MB and their multiple specific tags don't need to be supported as they would be if MB had to manage them separately.

I own thousands of digital comics and use ComicRack (sadly abandoned for years). I can organize, group, filter by Series, Volume, Number, Title, Published date, Released date, Crossovers, Imprint, Writer, Penciler, Inker, Colorist, Letterer, Characters etc.  (all these tags are scraped from the ComicVine site). Then would come the need to find dupes, convert etc., all things we can do with audio files in MB.

Documents (Office etc.) I don't know, I only have a few and I don't need  some specialized software. But images, videos, eBooks  have a lot of specific tags too. To support the most used digital files would mean support a huge number of new tags and/or custom tags and some new features you'll find even in the most basic specialized managing software.

As for video, managing them with MB without the ability to play them directly would be pretty much useless. Media boxes have their own integrated managing software and you can even install Kodi or Plex if you wish for something else. The only benefit would be on PC to watch videos from your HD/SSD by opening your video player automatically when you click on a video file in MB. I'm not sure how much people still do this.

Still, if Steven is temporarily bored by MB, I suggest a comic-book manager (joking )

7

MusicBee Wishlist / Re: ALBUM VIEW: Fill picture

« on: May 12, 2022, 01:03:17 PM »

If it's optional, I don't care. But if it's supposed to be the default, then -100. Covers are not always square. I wouldn't want my rectangular covers elongated or flattened.

8

MusicBee Wishlist / Re: 384kHz Upsampling

« on: April 08, 2022, 11:21:37 PM »

No it was accurate and there are decidedly 2 camps of thought. People who go by measurements and others who listen for differences. (blind or not)

Wrong. One camp trust science and double blind listening tests to prove theories. The other camp trust whatever they perceive in subjective listening tests, then claim it as a truth.

Proving the existence of the audible differences between a 44Hz file and the same file correctly upsampled to 384kHz is quick and easy for anyone 100% sure hearing it. All it takes is Foobar and its ABX plugin then doing the exact same thing than in a subjective listening test, ie differentiating the two files by their sound. After that, if you still hear it trusting your ears and only your ears, not your eyes, you can post the two files, your log and your audio hardware used, and the question is resolved for anybody on the planet. If ONE person proves it, the matter is settled, end of the debate, more time to listen to music instead of bickering on forums.  

The whole test would take 2 hours tops, including posting the results, less time that doing a YouTube video. But noone among the believers in that theory cared to do one, if any to prove himself he was right. No hobbyist, no "expert", no professional. Nobody, in all the years that belief has been going on, just like any other audio belief.

Obviously, I don't care if Steven was to add this feature, I just wouldn't use it, no harm done. I was just irritated by "I still see that 192kHz is the maximum in 2022". Like MB was crippled or late in the audiophile race for higher/bigger is better. Will some people absolutely need 768kHz in 5 years? Coming from people dismissing measures is pretty ironic, when the whole topic is about kilohertz .

9

MusicBee Wishlist / Re: 384kHz Upsampling

« on: April 07, 2022, 12:44:00 AM »

This debate has raged for quite sometime, some people find it a clear advantage, some do not.

-1

Actually, like with any other audiophoolery, there's no debate. Some say there's an audible difference, others say that makes no sense and ask for a proof. But the first group answer with mock indignation they have nothing to prove and/or measures don't tell the whole story and/or ABX listening tests are flawed. End of debate before it even begun. 

10

Questions / Re: Bitrate checkers

« on: March 16, 2022, 06:10:19 PM »

Ultimately, I prefer to trust my ears and can easily pick out a 320 mp3 next to a flac or wav file, although could be (and have been) fooled if all I'm hearing are 320 mp3's

It's almost impossible to hear differences between a properly encoded 320 kbps MP3 and its lossless version. You can occasionnaly identify such an MP3 by its pre-echo artefacts in some instruments like castanets, but not much else. I'm talking about a controlled double-blind test, like an ABX, which is the only test you can trust (for yourself or other people).

Even with golden ears and good training in spotting MP3 artefacts, there is no way you can "easily" pick out a 320 kbps from a lossless. So here are some leads:

* You're comparing two different editions with mastering differences
* One of these files has been converted from a sub-par version
* The two files have different sound levels (always use Replaygain before comparing)
* Placebo effect

Please don't feel insulted by the last one. Placebo effect is human and all of us are subject to it, without exception.

As for verifying if a lossless album hasn't been converted, there's a very trustful way in most cases (not all): AccurateRip. This can be done on a complete ripped CD only (be it a single or a full album), but not lone tracks. Download and install CUETools: http://cue.tools/wiki/CUETools_Download#Download . In the Action box, check Verify. Then drag and drop your album folder (with or without a .cue) in the Input box and press Go. A log will be displayed in the main window. Set the options to your needs (writing the log in the album folder, recursive analysis etc.).

The log will give you results from both the CUETools and AccurateRip database. The most trustful is the AccurateRip one. Most logs will look like these ones (I edited them down to the important parts) :

[CUETools log; Date: 05/01/2016 00:16:18; Version: 2.1.6]
[AccurateRip ID: 000826fb-003728c0-71068c08] disk not present in database.

This is a CD-R home-produced by friends, never released to anyone but our circle. Obviously, it's missing from the AR database. But what if it was a commercial CD? Then you have to worry about the validity of this supposed lossless rip. No ID in the AR database can only happen if nobody ever ripped this CD in an AR-featured ripper (like MusicBee, obviously, but also Foobar2000, XLD, dBPowerAmp and lots of others). This doesn't mean this rip is not perfectly fine and 100% lossless but there's a doubt. If it's a well-known album, then it can be a transcoding or a counterfeited indonesian edition etc.

[CUETools log; Date: 16/01/2022 19:01:16; Version: 2.1.6]
Pregap length 00:00:33.

[AccurateRip ID: 0010e797-0092d206-89095a0b] found.
Track   [  CRC   |   V2   ] Status
 01     [d59f6fd8|19db8a5d] (0+0/3) No match
 02     [19487148|207beb90] (0+0/3) No match
 03     [084c706c|e2cad204] (0+0/3) No match
 04     [8fcbba20|92e24646] (0+0/3) No match
 05     [404bf14b|0638f188] (0+0/3) No match
 06     [4a0c4d05|42e2884c] (0+0/3) No match
 07     [d244f8bb|b25f4117] (0+0/3) No match
 08     [7bc34679|e04ecb07] (0+0/3) No match
 09     [1865b616|7e0e92ec] (0+0/3) No match
 10     [bcf3ed5a|78e44ac6] (0+0/3) No match
 11     [a221e222|ca0f5756] (0+0/3) No match
Offsetted by -6:
 01     [8f5321ca] (0/3) No match (V2 was not tested)
 02     [72840ea0] (0/3) No match (V2 was not tested)
 03     [12bfccfc] (0/3) No match (V2 was not tested)
 04     [c87b82f6] (0/3) No match (V2 was not tested)
 05     [65fa96b5] (0/3) No match (V2 was not tested)
 06     [67882f7b] (0/3) No match (V2 was not tested)
 07     [cd0ae745] (0/3) No match (V2 was not tested)
 08     [6c6cb3f9] (0/3) No match (V2 was not tested)
 09     [29213c7e] (0/3) No match (V2 was not tested)
 10     [6956ce94] (0/3) No match (V2 was not tested)
 11     [ee6dbdca] (0/3) No match (V2 was not tested)

This CD has an AR ID with 3 copies registered but the rip doesn't match any of the 3. It may be suspicious or not, depending on the rarity/popularity of the CD. In this example, this is an obscure 1998 blues album from John Brim and Pinetop Perkins, released by an austrian label. One one hand, my copy could be from a reissue. Very small labels don't press huge quantities and they often repress on demand. On the other hand, Discogs lists only one edition of this CD. But maybe this rip hasn't been made in a secure ripper and isn't bit-perfect. It doesn't mean it's a transcoding but there is a doubt.  

[CUETools log; Date: 13/01/2022 23:37:49; Version: 2.1.6]

[AccurateRip ID: 00148b2f-00dc767c-c309930e] found.
Track   [  CRC   |   V2   ] Status
 01     [a6af0a10|37d4a747] (10+23/36) Accurately ripped
 02     [0e12503b|2000c2de] (10+23/36) Accurately ripped
 03     [86b307e6|f913b7d7] (11+24/38) Accurately ripped
 04     [e30a6e9f|ba7067a9] (10+24/37) Accurately ripped
 05     [f4fceca6|88d1b62e] (10+24/37) Accurately ripped
 06     [d75cf4cb|6dc314a1] (10+24/37) Accurately ripped
 07     [9230d059|7c65d3f7] (10+24/37) Accurately ripped
 08     [37ffdacb|76631d5e] (10+24/36) Accurately ripped
 09     [104d2651|2c3e10e1] (10+24/37) Accurately ripped
 10     [fae45614|934b713a] (10+24/37) Accurately ripped
 11     [b1d3552e|1e6dc70f] (10+23/35) Accurately ripped
 12     [d4bec96a|50446e9e] (10+23/36) Accurately ripped
 13     [b995b13a|1223f04a] (10+24/37) Accurately ripped
 14     [e4bb4c10|d5e5bf6a] (10+24/37) Accurately ripped
Offsetted by -1540:
 01     [1915db1e] (03/36) Accurately ripped
 02     [4f4b6e8a] (03/36) Accurately ripped
 03     [c17095f8] (03/38) Accurately ripped
 04     [7e01b51b] (03/37) Accurately ripped
 05     [5ee22f08] (00/37) No match (V2 was not tested)
 06     [b911904a] (03/37) Accurately ripped
 07     [04fc996a] (03/37) Accurately ripped
 08     [b8e8fa7d] (02/36) Accurately ripped
 09     [de757d6a] (03/37) Accurately ripped
 10     [7f47797d] (00/37) No match (V2 was not tested)
 11     [fede457f] (02/35) Accurately ripped
 12     [3aee5f85] (03/36) Accurately ripped
 13     [85e9e706] (03/37) Accurately ripped
 14     [566f4672] (03/37) Accurately ripped        

This one is from the 1989 edition of The Complete Capitol Recordings, Vol. 1 of Art Tatum. No doubt here: this is the real deal. More than 30 people have ripped this CD and got the exact same CRC. You don't have to worry about a possible transcoding. This is the kind of log you'll see most of the times. Even 1 or 2 matches means you don't have to worry. No transcoded rip can match a logged lossless rip in the AR database.

[CUETools log; Date: 16/03/2022 17:44:38; Version: 2.1.6]
Padded some input files to a frame boundary.
[AccurateRip ID: 0046f85a-052d641a-7412071a] disk not present in database.

No doubt either with this one, but in a bad sense. The "Padded..." line means it's been transcoded. Not all transcodings can be identified by this padding, but if CUETools had to pad each track to a frame boundary, then you're 100% sure there was a transcoding in the chain.

As you can see, this CUETools verification isn't just about transcodings but also about bit-perfect rips, so it's inducing an additional level of paranoia and despair.    After all, is a non-transcoded but badly ripped CD still lossless? You also have to know some commercial CD can be mastered from MP3. They're rare but they exist, especially with labels reissuing public domain music. Lots of bad stuff here, soundwise. They don't have access to the tapes so they source their CD from whatever they find. But some well-established labels did this, too.

Again: it's rare, no need to worry much about it, just be aware of it. I have such a CD, a expanded reissue of an english 80's pop band, The Maisonettes. The label is Cherry Red, a perfectly legitimate english label, the music is copyrighted, and nonetheless the CD was mastered from MP3. Not a big deal, it's not a great album or a great band, I bought it for memories and I'm not even sure it would make a difference if it was mastered from tapes.

11

General Discussions / Re: Why isn't this project open source?

« on: March 09, 2022, 11:36:24 AM »

This is again not true. Foobar and other software aren't more popular specifically because they're too old. An old piece of software usually (not always, but usually) means that it has an old design has well (not talking about the UI but the overall system itself). Also, the most important developers of most open-source projects are the top contributor, which are usually the creators of the said projects.

You're not answering my rhetorical question and your "not true" is followed by a lot of nonsense (Foobar not popular because it's too old? lol). Why is 13 years old MB better than any open source audio player, whatever its age? According to your open source zealotry, the "community" should have coded a much better player. Here's a list of the supposed "best" 25: https://listoffreeware.com/free-open-source-music-player-software-windows/ . Here's a not rhetorical question: why don't you contribute to one or several of them to improve them and add missing features that you love in MB?

If a system is well-designed from the start and appeals many users, and suceeds in maintaining this position for years, then it's not a matter of being open-source or not ; it's just a question of being a software that keeps itself up-to-date with the current users' expectations.

I'm not into the broad generalizations you're using to avert the questions, I'm talking about people coming to a forum and saying first : "your software is the best, I love it" (which I, too, think of MB) then "you should free your code".

You also say "The other irony is that asking for this or that on open source forums will expose you to the dreaded answer "if you're not happy, code it yourself, you know where is our repo, right?"."
No, this is not how it happens on most forums. I've contributed to dozens of open-source projects in the past, and if you want a feature usually there will be people willing to implement them - notably because most people asking for features aren't developers. In fact it's harder to find a project that does what you say than the opposite.

So if it was true (which is not), you make my question even more relevant: why using MB and asking Steven to free his code instead of having contributed to one of the hundreds of open source audio players with the help of a whole world-wide community? Which according to your open sourcing arguments should have produced a much better player than MB for years, isn't it?

Now about the question of "To be honest, that last paragraph was mainly me taking out my frustration because it is highly unlikely that there is an open-source alternative that is anywhere near being anywhere near as good as musicbee. It is truly a shame."
As I have already said multiple times before, closed-source has its advantages: you don't have to deal with other people making pull requests to your code, you don't have to look into that, you gain a lot of time from this, and you can focus on what you actually want to do: develop your own software. You also miss a lot of things, like code review by other people, contribution by other talented developers, refactoring and optimization and bugfixes from other people without having to do anything - because yes, that's also what happens with open-source projects.

No, it only happens with some open-source projects. We're talking about a hobbyist program, a Windows desktop audio player in which no corporation or administration has any interest. Most hobbyist open-source progs are a one-man operation and they become abandonware the day the dev lose interest.

There are tons of huge and successful open-source projects in the community, and the bigger a project is, the more it usually gains from being open-source (do you know about Linux?)

Yeah, I've known about Linux since last century and I know about Firefox and FLAC and Apache, all big projects with a huge appeal and/or fundations/corporations/administrations backing. You won't stay on the subject, are you? Which is a desktop audio player among hundreds of them.

This is more of an insult that a constructive argument. How can you even know those people are useless? Many of us are asking for the program to be open-source because it can benefit the community without costing anything to the main developers as long as he doesn't accept PR - now I can still understand he doesn't want to do that, but it doesn't make us "whiners" or "bossy" as we are actively trying to improve the software as well.

How do I know those people are useless? Easy: for 20 years I've always read "open the code so others can improve/continue it". I've NEVER read "open the code so I can help on this or that, I'm a developer and I have some good ideas for your program". If these numerous devs supposed to help Steven (or Peter for Foobar) exist, why don't they announce themselves as such? But no, it's always "let them help". So where are "they"?

You're no exception, even if you suddenly remembered you contributed to dozens of projects. Actually, you've been using MB for 2 years and never even helped someone on the forum which is strange for such a willing contributor. Hell, I can't code and english isn't my native language so I'm mostly useless here but at least I'm helping some MB users on a french forum: https://forum.hardware.fr/hfr/VideoSon/Traitement-Audio/musicbee-lecteurs-windows-sujet_155375_1.htm .

Also, I have a side question: what would happen if something would come to happen to Steve? Does anyone else here have an access to the source code? Or will the project suddenly die because no one can access it? It's another problematic with closed-source software which I hope has already been solved.

You know very well what'll happen: MB will become abandonware, by the way not different from ten of thousands of open-source projects. If you know for a fact that MB will never die if its code is freed, I want to buy your crystal ball.

Now I'll conclude this by thanking again Steve for his amazing work on MusicBee, telling again for people who don't seem to understand that that we aren't trying to make up his mind on the subject -

This whole thread and your posts are exactly that and nothing else: trying to make up his mind on the subject.

12

General Discussions / Re: Music Bee source code

« on: March 09, 2022, 12:02:12 AM »

To be honest, that last paragraph was mainly me taking out my frustration because it is highly unlikely that there is an open-source alternative that is anywhere near being anywhere near as good as musicbee. It is truly a shame.

That has been said about Foobar2000 for more than 15 years too. Which begs the question: "why are free closed-sourced Foobar and MusicBee (I could add AIMP which own its niche of Winamp orphans) better than anything open-source?" Since open source software is supposed to be improved by a crowd of talented volunteering devs from all over the world, why are Amarok, Clementine, Audacious etc. still inferior to Foobar or MusicBee?

Amarok is 18 years old, Clementine 12, Audacious 16, the community of devs had plenty of time to improve them to the point of replicating each and every feature, including the UI, of any closed source player, with forks if needed.

The answer is probably because open sourcing harassers on the forums are not planning to improve or carry on any project. They can't code (I don't blame them for this, I couldn't either), they're waiting for others to do it.

The sad irony is that the devs harassed by these zealots are the most generous: the ones that don't ask money for their work. Sell your program 5$ and nobody will ask you to open your code. The other irony is that asking for this or that on open source forums will expose you to the dreaded answer "if you're not happy, code it yourself, you know where is our repo, right?".

Sorry for the rant but I'm sick of these people harassing the devs of some of my favorite programs, year after year. Some are whiners, some are bossy, all of them are useless. Everybody knows about open source software, the devs better than anybody else, so there's only one reason you need to know why a developer doesn't open his code and that's because he doesn't want to. End of story.

13

General Discussions / Re: What happens when Steven dies?

« on: October 19, 2021, 05:35:36 PM »

(...)in combination with JPlay and Fidelizer.

Thanks, you made my day. 

14

Tips and Tricks / Re: How to change MusicBee icon (fastest way)

« on: November 25, 2020, 12:11:14 AM »

So you need to download a program, learn how to use it and risk damaging the .exe. Then you need to redo the whole process every time MusicBee is updated or patched, which is nearly every month. It's the most geeky way but definitely not the fastest. I'm not even sure tampering with the executable is permitted by the licence.

Edit: I see from your posts that you're coming from Winamp which is dead since 2007 if you don't count that half-baked bug-ridden 2018 version. In that case, changing the icons the hard way may make sense. Luckily for us, MusicBee is alive and well and constantly evolving so don't mess with the executable. 

15

MusicBee Wishlist / Re: Internal Performer tag (Artists: Performer)

« on: January 11, 2017, 11:12:23 AM »

You're right, I mispelled it "Artist: Performer". But as you said, virtual tags don't do multiple values anyway so I'm back to square one. I can't have both sorting and multiple values with Performer or Artists: Performer. Rats.

I only use FLAC with Vorbis tags and WavPack with APE tags, hence my confusion with the "xxx; yyy" formatting.

Thanks again for your continued help, psychoadept.