Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - rygle

Pages: 12
Excellent! Me too!

@ 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 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

Quote from: hiccup
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;

Quote from: hiccup
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.

Quote from: hiccup
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.

Quote from: hiccup
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.

Quote from: hiccup
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?"

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?

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

Now that is just pure sarcasm aimed to be derogatory. I would have thought a "hero member" would have been above that. I have tried to be polite, and I have tried to help the community, but when I call you out on being rude, you just become more so. You should be ashamed of the way you are talking!

Yes, Windows has primarily handled file extensions using the last three characters of a file name, but there are exceptions to the rule. For a start, .html, .jpeg - windows has not been locked to 8.3 since Win95. That is more than two decades ago that Windows broke away from DOS limitations. Back in the old days Windows *had* to call those files *.htm and *.jpg, and one of them stuck, but the other didn't, because people found *.jpg easier and there was no need to keep the longer version and the rules had changed. But *.html was definitely an exception to the old 8.3 rule that is now ubiquitous. We are not limited by 8.3 because technology has moved on. Now we also have *.docx, *.xlsx and more. Now you can also have long file names and spaces and that is all accepted.

That is like grammar - you would be hard pressed to find a language that does not break its own grammatical rules at times because grammar is a snapshot of usage at a given time, and usage changes, so grammar has exceptions, and then with time the snapshot incorporates changes. The grammar purists argue over the exceptions, but every year dictionaries incorporate new exceptions as accepted grammar and eventually even the purists stop arguing over what had been common use for years. The exceptions stay, and people know that in 99% of cases it happens this way, but in 1% it happens that way, and that way is OK, because grammar has caught up with actual use.

Double file extensions have been around for decades. *.tar.gz has been around for decades. It is unusual, but it is accepted. People use it all the time. They understand that both the tar and the gz mean something about the type of file that it is and the processes that it went through to become what it is. Some people have used *.tgz instead, partly because of the old 8.3 rules, and partly because it is easier, and that is fine, but the *.tar.gz double extension is still the dominant accepted file extension for that sort of file. People understand and accept that someone decided on a naming schema for that sort of file a long time ago, and that it means something, and so that is good enough for them. It is unusual, but it is technically feasible and it is logically feasible to have a double file extension. It is allowed.

Now the designer of lossywav and lossyflac designed a new standard that augments an old one. He put it up on hydrogen audio, just because he chose to, including the naming schema. He also put the naming schema in the source code. Those who choose to use lossywav / lossyflac would normally choose to follow. It is technically feasible on any platform. It is logical that the files have a double file extension. We are not limited by is allowed and, in fact, useful. The double file extension was settled on to alleviate concerns of the community that people might not be able to distinguish files that have been through the LossyWAV process prior to being encoded as flac. The audio purists would riot if there was no way to distinguish flac from lossy flac. In fact, even after the double file name convention was announced, it took a long time to convince the purists that everything was going to be OK, and that they could go back and distinguish their own rips, but more importantly they could distinguish other peoples rips. It is about clarity, about choice, about purity, about fidelity. All that stuff is important to a large portion of the audiophile community, whether they use it or not they want it to be able to be done, and there was much said about it until in 2007 or 2008 it was settled that the double file extension was the official way to safeguard flac while distinguishing lossyflac. The argument is over for the audiophiles and has been for a decade.

Now, many years later, a program starts using that standard. It did it well when encoding, but it removes the distinguishing file extension when moving files and renaming/organising them at the same time. This is something that could cause confusion, and therefore it is not preferable. It is something that is technically feasible, and easy to fix. It is allowed by every platform, *even Windows*. We are not limited by 8.3 anymore.

So really, what is the issue here?

It is not a technical issue - it is dead easy to incorporate into the MusicBee code
It is not a logical issue - the double extension is a rational explanation of the sort of file it is and it distinguishes files to safeguard purity for those to whom it matters
It is allowed by every platform - we have not been stuck with 8.3 for decades, thank goodness! I want my long file names!

I don't get why this is so offensive to you that you have to disprove it.

This is in usage, and has been for a decade. It is an accepted standard by the audio purists, who are some of the most difficult people on the planet to convince - and who you would hope can find a home with an app like MusicBee.

So why is it a problem? Really?

The question to ask is, is there a genuine use case? Is there a segment of the community that might want this? Is it hard to do? Will building this in cause problems for other functions? It might not be for everyone but I think if we get away from the polemic and think about use and technical issues, the answer is obvious.

The answer is, why not?

There is an official naming schema for lossyflac and lossywav files.

See the following where the author of LossyWAV describes the naming schema repeatedly;

MusicBee is not following this schema consistently, particularly when moving or copying files to an organised folder. It does follow the schema when ripping files in the first place.

The expected behaviour in this case would be that the official naming schema of .lossy.flac or .lossy.wav would be followed without dropping the .lossy part of the double file extension as described on the hydrogen audio wiki and various other places, or to give the option to drop the .lossy part of the filename extension, but only as an opt-out option.

See also the following discussion, which was an attempt to submit this as a bug that was moved to questions;

It's not expected behaviour. The only reason you're saying that is because you have decided that.

MusicBee treats the files one way when ripping them (I didn't make it call it .lossy.flac but thought it was a useful distinction when it did it, and have since learned that this is the official naming schema of the format) and a totally different way when moving them.

Further research showed that the lossyflac and lossywav formats are well known for over a decade for using a double file extension/suffix as their official naming schema to ensure that any player will still play the files. See for example;
* third post down referring to a Wiki article that is in the next link -

@frankz - I was pointing out that you were already speaking in a negative /derogatory/sarcastic manner with all your quote marks, and in linking to an article about what a suffix is. Do you really think I didn't know? Did you look at the wikipedia article on filename extensions that says in its first paragraph that they are suffixes? You are making false distinctions in order to make someone else look bad/wrong.

And if your point in linking to a definition of suffixes was that you can't have two suffixes then you are clearly wrong, because MusicBee is doing it in some instances (based on the naming conventions for lossy flac files as discussed above) and .tar.gz files have been doing it for decades. It is a little unusual, but it is not wrong to talk about suffixes or double suffixes as I did, and, in any case, the meaning of my words was plain to you and everyone, so to quote an article about the definition of suffixes is clearly an attempt at one-upmanship.

I wrote a bug report in good faith trying to help the community of an app I like very much, but you failed to treat my good faith report in the manner in which it was given. I wrote about an app behaving in two different ways at two different times, and you set out to shoot me down when I disagreed about it being expected behaviour. If it was expected behaviour, it would always refer to lossy FLAC files consistently in one way or the other on every occasion, and by rights it should name lossy flac files in the manner to which those who invented the format intended them to be named, that is with a double suffix /Filename extension. To say that lossyflac files must only have a suffix of .flac is to ignore the official naming schema of the format and show a lack of understanding of the format, which is preprocessed to lose unused significant bits in the noise floor, then processed again by the flac encoder.

The expected behaviour should be to follow the official naming schema of the format, or to give the option to drop the .lossy, but only as an option.

Actually, the good reason is that the file wouldn't play if it had the file extension .lossyflac but if MusicBee calls a file .lossy.flac it is still treated as a FLAC file.

Since you consider the dual suffix / file extension is not valid, perhaps the bug should be that MusicBee, or the LossyWAV plugin, generates it in the first place.

I would personally prefer a single suffix like .lossyflac, but I thought I should stick to the naming scheme that **MusicBee** chose because I figured if it chose to differentiate the files that way, there must be a good reason.

I don't understand why you are choosing to be rude to me just because I didn't agree with your solution. You are speaking like a forum troll, who doesn't listen but sets out to prove a point at all costs.

A file extension is a type of suffix.

If there is no such thing as a dual suffix / file extension, why the heck does MusicBee generate one in the first place when ripping? I didn't come up with the .lossy.flac double extension.

And what about .tar.gz files? Sometimes they have the .tgz file extension, but mostly not.

Can someone please move this back to bugs?

I think it was quite unreasonable to sideline it to questions when I clearly demonstrated steps to repeat the bug.

You might not think it's a bug because...
* you don't understand the issue
* you think it doesn't matter
* you don't care?

... But none of that means it's not a bug.

It is about the app treating file names differently in two different situations. If that doesn't matter then it shouldn't ever call files .lossy.flac in the first place.

The whole point of the way I did it is to not use the Filename. The idea of using Move to Organised Folder is to change the Filename while moving it. That's why there are naming schemas in that function.

The dual .lossy.flac suffix is generated by MusicBee when ripping into FLAC with the LossyWAV setting selected. It is not technically part of the name of the file, but a suffix that identifies what sort of file it is and should be considered the same as a single suffix such as mp3, ogg, wav

So, this should be considered a bug because MusicBee distinguishes plain FLAC from LossyWAV FLAC by using that dual suffix when ripping, yet when moving it ignores the dual suffix.

This is just as if it dropped all the .mp3 suffixes from your files when moving. That would be a bug, and so is this.

I wonder if there's a way to make this work for syncing to a USB stick/external device so that it would work for music in the car, on the phone (etc.). I know we can already level the volume, but it's not as advanced as this.

Steps to demonstrate bug
1. Rip files to FLAC using the lossy wav option to make files named {track name}.lossy.flac
2. Select Track/s
3. Right Click and select "Send To" -> "Folder (Move)" -> "Move Files to Organised Folder"
4. In the "File Organiser" dialogue, select folder, use naming template "<Album Artist>\<Album>\<Track#> <Title>" or similar.
5. The ".lossy" suffix will disappear from the file name in the preview, and from the actual file name if you proceed

1-3. Same as above
4. In the "File Organiser" dialogue, select folder, change the naming template to "<Album Artist>\<Album>\<Track#> <Title>.lossy"
5. The file suffix remains .lossy.flac for the preview and subsequent folder move

Same with Folder (Copy) -> Copy to Organised Folder

Using MusicBee 3.2.6760 on Windows 10. Don't know if this occurs in earlier versions.

Pages: 12