".lossy.flac" becomes ".flac" using "Move Files to Organised Folder"

[rygle]

If asking that the program treat files the same way in every situation is a feature request, I'm not sure what a bug is...

[Bee-liever]

While I don't agree with the "double-extension" identifier set out in the lossyWAV documentation, the fact that MB offers the use of lossyWAV and a link to the documentation setting out this suffix standard, then I do think it is a bug on MB's part not to provide a way to keep that double-extension when MB is the app doing the organising/re-organising.

[hiccup]

Hm, where do I begin?

Ah yes:
The boys and girls that created a lossy algorithm, and decided to give it the same extension as a well-known and popular lossles codec should be covered in hot oil and rolled into a hen house.
Doing that was a completely stupid idea to begin with.
So now you can not trust a .flac file of which you don't know the source from to be lossless anymore.
That's terrible, and in my opinion enough reason to avoid lossyflac like alcohol-free beer and never ever use or promote it.

So ideally, as an extension (I am not going into the argument of single- or double extensions) lossy flac should have been something like:
*.lossyfac
*.notflac
*.flacky

That's probably not going to happen, but I would fully support it if MusicBee would decide on something like that.
If somebody still insists to use lossy flac, the files could still be played, either by MB adapting that new extension, or by manually setting file associations.

That solution would be the best way to recognise these fake flacs.
(Yes, fake. The L in FLAC stands for lossless.)

Fourth best option would be to use and prevail this 'double extension' at least as a warning sign all over MusicBee.

[rygle]

The audiophile community has had all these arguments over a decade ago. These are the boffins who live and breathe this stuff and who are on a totally different (higher) level to most people on the MusicBee forums. But they are also a very significant part of the target market of MusicBee.

These are some of the most notoriously fussy and hard to please people on the planet, and they have decided a long time ago that this argument is settled, that this is a valid format, and that the naming schema is a valid naming schema.

It is not up to us to argue the validity of the format. MusicBee should either fully support it or not.

To say that MusicBee wouldn't want to fully support it is just like saying that whole segment of the audience are not that important.

But having said that, it seems you don't understand the format. The lossy part is getting rid of significant bits used to record total silence below the noise floor. Even though CD audio has about 90db dynamic range, most music only uses 15-20 at the most, so the other 70db or so is recording information for signal that is never used effectively, but takes up space. This silence is filtered out through a pre-processing stage, which is lossy, then the file is fed to the FLAC encoder. So the theory goes that the loss is only information that is totally redundant, and the actual audio signal is given the lossless treatment. This is sure different to the psycho acoustic treatment that is used in mp3, where sound is disposed of that is actually there but is effectively masked by other sound to the human ear.

To many people LossyFLAC means effectively no loss, but file size savings. To some people that's an abomination. That is why the two part file extension. It signals that it is a genuine FLAC file, and any FLAC compatible player/decoder will support it, but it has had the lossy treatment on data that LossyFLAC deems to be null.

The audiophiles have decided. Do we want to welcome them? Or say that their format is invalid?

[hiccup]

and who are on a totally different (higher) level to most people on the MusicBee forums

I usually cringe when somebody calls a fictional group of people 'of a higher level' then another fictional group of people.

The fact that most MusicBee forum members know how to keep their posts on topic, and mostly discuss issues specifically relevant to MusicBee itself doesn't mean many of them don't have a deeper knowledge of- and experience with many technical aspects of audio, and/or have excellent ears and equipment.


Lossy flac is lossy
- The guys who created it call it lossy
- It removes audiobits, so it is not bitperfect anymore, so it's lossy.
- If it was not lossy, they would have just added some additional 'flac9' setting to the existing FLAC encoding algorithm, so it's lossy.

You are probably confused with the equivalent of the never-ending 24 bits vs 16 bits debates.
In my opinion (and many very high level groups of people agree on this), 24 bits audio contains no useful additional audio information compared to 16 bits audio.
(At the end-user ('audiophiles' included) playback level that is, at the recording/mixing/mastering stages it is an invaluable asset)

But would I agree to call a 16bits file that was converted from a 24bits source, 24bits?
Of course not. It may sound absolutely identical, but it is not bit-identical.
So compared to the 24 bit source it is lossy. (well, actually not in all cases, but certainly in most)
So any debate on lossy flac vs lossless flac is comparable to that. (and boring after 10 years)


By now this thread is mostly about arguing single vs. double extensions, lossy vs. lossless audio, calling something a bug or not calling it a bug.
That's all fine, and perhaps that all interests you, but you should then maybe consider to change the title of this thread?

If you are really interested in having changed what you think should be changed, it would be wise to follow the advice that experienced members have given you before:
Create a brief and concise wishlist topic.
If you think this thread helps building your case, you could add a link to it.

[rygle]

I usually cringe when somebody calls a fictional group of people 'of a higher level' then another fictional group of people.

The fact that most MusicBee forum members know how to keep their posts on topic, and mostly discuss issues specifically relevant to MusicBee itself doesn't mean many of them don't have a deeper knowledge of- and experience with many technical aspects of audio, and/or have excellent ears and equipment.

There are people who are of the order that they can make audio formats, and there are people who are not. I am not, and I highly doubt you are. Nor do I think that any of those who have commented on this post, nor most of the people using MusicBee or on the forums can make an audio format.

There are also people who care a lot about super fine details of audio formats. I am also not one of them. I dabble around the edges. I would hazard a guess that most of the people on the MusicBee forum are similar to me in that respect.

There are people who are far more passionate than me about all of this. People who care deeply that the ".lossless" part stays on their file name. I am not really one of them either. I just saw that MusicBee put it in, and I realised it was somewhat useful, and I tried to help the community by preserving its proper use.


People act as if I am asking for something that is difficult, when in fact it was something very simple - that MusicBee not treat file names in two different ways in two different functions. All I was asking for was that MusicBee use file names consistently. A simple change to a regex reference in the code would fix the problem, and not create any problem for any other use case. Probably one or two lines of code. Something a little like the attempt of @Frankz earlier in this topic, but not quite, and internal to the file handling dialogue, not having to be added as a workaround by the user every time.

I did not choose to make this difficult, I spelt out a clear, simple and concise set of steps to replicate a bug, which is what I have been used to doing in many programming/bug testing projects previously, but I am absolutely amazed at how difficult forum members have tried to make this, how little they have listened to the simple problem I tried to highlight, and how much they have tried to take it off-topic, some while insisting that I am the one taking it off-topic.

What people did was make a mountain out of a molehill and then assume I was either dumb or difficult, so I have politely continued to defend my simple request.


A few things that people have tried to (wrongly) argue, all of which have actually been taking this off-topic, and which I have refuted fully in every case in order to bring it back on-topic

* MusicBee was acting as intended/designed/expected - No. MusicBee is being inconsistent in handling file names from one function (ripping using the LossyFLAC switch) to another (moving the generated files to organised folder)
* That my naming filter in Move To Organised Folder was wrong and I should use <filename> instead of <Disc-Track#> <Title> - No. In fact to use <filename> defeats the purpose of using Move to Organised Folder, which is designed purely to *change* filenames. If you use the <filename> tag, the file name will not be changed at all - it literally does nothing, because the input <filename> equals the output <filename> when <Disc-Track#> <Title> does not necessarily equal the original <filename>
* There was a suggestion that a suffix is not a file extension - No. the Wikipedia article on File Extensions says that in its first line
* That there is no such thing as a double file extension - No - .tar.gz anyone?
* That the LossyFLAC format is invalid - No. It was valid enough that it has been accepted for ten years, and that there is a switch already in MusicBee to use it, which is how I came across it.
* That the *.3 file format is the only permissible file format. Well, the *.3 format doesn't exist any more, and dots are simply characters, and the total file name is now up to 255 characters, and then only limited by not being able to use a few special characters
* That Musicbee is only on Windows, and therefore, again (snore!) we should stick to 8.3 - Well, have you ever heard about cross platform file use? Or MusicBee users who use several platforms? Or this topic about running MusicBee on Linux? Or this topic about running MusicBee on Mac?


Now, if all that off-topic rubbish doesn't make you snore, add to it *your* additional attempt to take it off topic;

Lossy flac is lossy
- The guys who created it call it lossy
- It removes audiobits, so it is not bitperfect anymore, so it's lossy.
- If it was not lossy, they would have just added some additional 'flac9' setting to the existing FLAC encoding algorithm, so it's lossy.

I *never* claimed that LossyFLAC is not lossy. How could I? It's in the file naming schema, the one that I am arguing should be kept, not dropped during a Move operation!

I actually stated in my most recent post that LossyFLAC was lossy, and used the phrases; "The lossy part is getting rid of significant bits used to record total silence below the noise floor", "This silence is filtered out through a pre-processing stage, which is lossy", "the loss is only information that is totally redundant", "To many people LossyFLAC means effectively no loss, but file size savings. To some people that's an abomination" and "it has had the lossy treatment on data that LossyFLAC deems to be null"

To argue that I said LossyFLAC is not lossy is totally false. It just shows you lack basic comprehension skills.
To argue that any of the above rubbish is me taking things off topic is totally false. It is people like you who don't read the five times or more I say "lossy", or the forum topic title, and similar misreadings or assumed readings of what I have written.

You are probably confused with the equivalent of the never-ending 24 bits vs 16 bits debates.
In my opinion (and many very high level groups of people agree on this), 24 bits audio contains no useful additional audio information compared to 16 bits audio.
(At the end-user ('audiophiles' included) playback level that is, at the recording/mixing/mastering stages it is an invaluable asset)

But would I agree to call a 16bits file that was converted from a 24bits source, 24bits?
Of course not. It may sound absolutely identical, but it is not bit-identical.
So compared to the 24 bit source it is lossy. (well, actually not in all cases, but certainly in most)
So any debate on lossy flac vs lossless flac is comparable to that. (and boring after 10 years)

I did not say anything about 16 or 24 bit, nor did I mention sampling rates, or anything but file names. That is *you* taking things off topic. You might as well state that I was saying the guy on the grassy noll didn't shoot Kennedy, or that the moon landing was faked. I didn't say any of that either.

By now this thread is mostly about arguing single vs. double extensions, lossy vs. lossless audio, calling something a bug or not calling it a bug.
That's all fine, and perhaps that all interests you, but you should then maybe consider to change the title of this thread?

I was very careful to keep the name of the topic simple and on-topic. It was about file naming being inconsistent between two different functions of MusicBee.

If you are really interested in having changed what you think should be changed, it would be wise to follow the advice that experienced members have given you before:
Create a brief and concise wishlist topic.
If you think this thread helps building your case, you could add a link to it.

Now, that just says to me that you didn't even read my first post, where I created a brief and concise request as a bug before it was wrongly moved to questions.

And when I asked politely, saying please, that it be moved back to bugs, I was dismissed, so I provided evidence to refute everything that has been thrown up, and yet it still is attracting people who are dismissing it on the basis of things that I have never said.


And so I actually re-filed another simple, brief, on-topic bug report, linked to this topic, long before you suggested it.


So, to sum up

I filed a bug request with a simple, clear title, asking for something simple, where MusicBee was behaving as expected in one function but not another. I asked for consistency.

I provided a simple case to demonstrate how to replicate the bug.

I have at all times tried to keep this on topic, simple, polite and factual.

I don't understand why one person moved this out of bugs in the first place, and why it couldn't be moved back when requested. I also don't understand why now three people have kept arguing so hard against something that is simple to understand, extremely easy to fix and permissible in terms of file naming conventions.

Sure, double file extensions are not the norm, but they are not unheard of, and have been commonly used for decades, even on Windows of late. Additionally, this is using an externally derived format where the intricacies of file naming have been argued and settled for ten years, and I did not request anything but consistent use of this external format. MusicBee should either use it as is, or not use it at all, or have an option to modify the behaviour either way consistently in every case.

Sure, you might not like the LossyFLAC audio format, or you might think there are enough formats out there, but that doesn't mean it doesn't have a valid use case. I personally don't use AAC, ALAC, WAV or many other formats, but I am happy for you and others to use them and to have MusicBee function consistently while you are doing so.

Sure, you might think that this is a corner case, and that might be true, but it is a very very simple fix that will not affect any other usage scenario for MusicBee.

If there is a way to fix an inconsistency that is easy, acceptable and which preserves all existing functionality, while also making a part of the MusicBee market feel listened to, the only question is; "Why not?"

[redwing]

Not sure why this simple report/request has to turn into an endless debate.

I think the OP made a valid point that MB should, as long as it supports the format, preserve the unusual double suffix for lossyWAV files (not just lossyFLAC but all lossyWAV formats) via file organizer, whether it's a bug or a feature request. If that ".lossy" part gets removed from filename while re-organizing, people will have hard time to identify them from other normal files.

Another thing is that ALAC doesn't need that option in the File Converter setting since it's not supported. Instead WMP could have one as it supports WMP lossless format: https://wiki.hydrogenaud.io/index.php?title=LossyWAV#Supported_input_formats

[captain_paranoia]

> That the *.3 file format is the only permissible file format. Well, the *.3 format doesn't exist any more

I don't think anyone has said that (MB supports .flac, so is happy to deal with 4-character extensions). What they have said is that Windows only considers the last .ext extension as a valid file extension. Try clicking one of your track.lossy.flac filenames in Windows Explorer, to change the name. Windows will select everything up to the last extension for edit (leaving the final extension outside the edit scope).

I'm pretty sure that linux shell filename processing commands (e.g. /bin/csh $file:r or /bin/bash basename($file$)) will also only remove the last .ext, and would consider the .lossy bit as part of the root filename.

[hiccup]

So you are not willing to create a simple wishlist request for this, as suggested and explained to you many times now, but you choose to prolong this silly debate in this thread?


Fine by me, I have some time, and will only address some misinterpretations and false suggestions you are making about what I have said.


You really shouldn't accuse others of making off-topic responses where you instigated those yourself.
You are the one that raised the issue of the sound quality of lossyflac in this thread.
I did not.
I never said anything like the algorithm having no purpose, qualities, or a right of existence.
I never said that it should be removed from MusicBee.

(well, I did say something along the lines of that in it's current implementation and naming it should be avoided, dis-encouraged, and I personally would never use it, just like alcohol-free beer, but that is clearly a personal opinion)

I did say that the original decision of using the word 'flac' in the extension has been a terrible one.
This lengthy and messy thread alone is some proof of that.
The word 'lossyflac' in itself is a stupid and confusing contradiction.
How can somebody say it's not? It's literally saying 'lossy lossless'.

Then you brought up 'audiophiles and high level people'.
You did not do that to substantiate your original argument about preserving the 'lossy' part of the filename.
(which I would actually support, what you don't seem to grasp)
You brought that up because you believe the MusicBee forum members needed some education about audio algorithms.
But it goes completely beyond me what that has to do with the original intention for creating this topic.
So by doing that, you actually made this thread becoming more and more off-topic yourself.

This thread is not read by the participating members alone. Others will read it too, people will stumble upon it by using google, and it will be read a long time after it has been closed. (and I really hope that happens sooner than later)

So when you started mixing up issues of the naming conventions of lossyflac with the sound quality of it, you insinuated on a public forum that lossyflac is actually just as good as flac (because audiophiles and high level people say so).
So don't act surprised or annoyed when you get responses to that, explaining to you (and others) why and how it is actually different and not lossless.
And my effort to explain it by means of the analogy to 24 vs. 16 bits is technically valid, and also not off-topic.

What do you want to argue about next?

[rygle]

@ Hiccup

Most of what you have just said clearly demonstrates that you have not made any effort to hear what I've been saying.

* I did not choose for this thread to be long. I only requested a simple change to improve consistency in handling file names. It's there in the first post.

* I have given explanations when people have said things that called for an explanation, such as;
 - this is a non-bug, this is expected behaviour - calls for an answer about why I think it is not expected behaviour
 - You should try x,y,z actions that don't align with consistent file naming - calls for an answer about why this is inconsistent with expected behaviour
 - "you are probably confused with the equivalent of the never-ending 24 bits vs 16 bits debates"

* If it's a bug, why would I not report it as a bug? I have been involved in bug testing for lots of apps and believe I have a good idea of what a bug is. I have said all along that this is purely about inconsistent handling of file names, and that is a bug.

* If you don't like "fake flacs" and you think things should be done to the author with oil and chickens because "now you can not trust a .flac file", then you should understand exactly why I wanted to maintain the distinction in the name. I think the naming scheme strikes a useful balance that maintains an appropriate distinction.

* You said; "Then you brought up 'audiophiles and high level people'. You did not do that to substantiate your original argument about preserving the 'lossy' part of the filename." Well, the *only* reason I spoke about audiophiles is that a bunch of them debated this over ten years ago and the argument over naming was settled by them. You seem to think they're idiots and have said as much in several colourful ways. I have never claimed to be an expert, but merely stated that the debate is over, however you, among others, seem to want to debate. I just want consistency in file name handling.

* You mention concern that other people will read this. I have not been the one insulting others, though I have called out such treatment. Your recent description of the lossyflac developers is particularly flattering for google's data warehouse.

* I did not raise the issue of sound quality, but explained the lossyflac format briefly in the context of your strong expression of disbelief that the format was valid, including statements about "fake flacs". And, yes, I certainly believe that you in particular "needed some education about audio algorithms" and still do. Have you read how lossyflac/lossywav works? Have you read the detailed explanations and the accounts of the depths of testing that were put into this, just for the experimental phase before the first release? I didn't think so...

* I am not confused about the 16/24/32 bit and/or 44.1/48/96kHz debate. I would highly recommend the videos on the Xiph.org website about this topic - they are very informative and I watched them again only about a month ago!

* I didn't say or insinuate that audiophiles think lossyflac is as good as flac. They say that it is near lossless. I have never said any different, and to claim that I did is plain false.

* I have never said lossyflac is completely lossless. It is near lossless because it drops significant bits below the sound floor, but it is not bit for bit lossless, no, and I have never said any different. I described that it has a lossy stage followed by a lossless stage. Hence the need for a double-suffix denoting the two processes.

* To say that I mixed up file names and audio quality is plain wrong. I was responding to your rant in the previous post

[hiccup]

@ Hiccup

You persist in confusing and mixing the issues of audio quality and naming conventions.
You keep repeating the same things that have already been said many times in this thread.
You persist in refusing to create a wishlist topic.

Have fun, I'm done here.

[rygle]

Excellent! Me too!