Author Topic: ".lossy.flac" becomes ".flac" using "Move Files to Organised Folder"  (Read 5783 times)

rygle

  • Jr. Member
  • **
  • Posts: 22
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

Workaround...
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.
Last Edit: July 15, 2018, 11:05:59 AM by rygle

frankz

  • Sr. Member
  • ****
  • Posts: 3834

rygle

  • Jr. Member
  • **
  • Posts: 22
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.
Last Edit: July 29, 2018, 10:23:54 AM by rygle

rygle

  • Jr. Member
  • **
  • Posts: 22
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.

frankz

  • Sr. Member
  • ****
  • Posts: 3834
Sorry, but it's not a "bug."  Bugs are errors due to unexpected behavior. This is expected behavior.  

There is only one extension to a file - the last .*** portion of a file.  There's no such thing as a "dual suffix" extension no matter how much you want there to be one. You can have as many periods as you want in a file name, but only the last one denotes that what follows is the extension.  If it were an actual usable extension, it would be .lossyflac.

If you don't want it to alter the filename portion of the existing filename.extension construction, use the <Filename> element in your template and have it preserved.  You can set this to <Track#> <Title> during the actual conversion to have the filename portion as you like it before this final step.

I "understand" it plenty, and "think it matters" and "care" enough to give you a workable way to handle it in multiple replies.  None of that means that this expected behavior is a bug that needs to be addressed by anyone but you.

Definition of suffix
: an affix occurring at the end of a word, base, or phrase
Last Edit: July 29, 2018, 07:19:30 AM by frankz

rygle

  • Jr. Member
  • **
  • Posts: 22
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.
https://en.m.wikipedia.org/wiki/Filename_extension

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.



Last Edit: July 29, 2018, 08:58:29 AM by rygle

rygle

  • Jr. Member
  • **
  • Posts: 22
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.
Last Edit: July 31, 2018, 08:43:29 AM by rygle

rygle

  • Jr. Member
  • **
  • Posts: 22
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.

Havokdan

  • Full Member
  • ***
  • Posts: 237
Well, if the application behaves as expected, why would it be considered a bug? Well, you can make a request for "lossy" to be considered part of the extension or the MusicBee creates "lossyflac" instead of "lossy.flac" for example.

frankz

  • Sr. Member
  • ****
  • Posts: 3834
You are speaking like a forum troll, who doesn't listen but sets out to prove a point at all costs.
Calling names never solved anything.

I don't understand why the actual way to handle this non-bug (using the filename in your organization template or - if you're really set on generating the file name each time even though it's already been generated once - something like "$If($Contains(<Filename>,lossy)="T",<Track#><Title>".lossy.",<Track#><Title>)" ) is a problem.

The application is doing exactly what you've asked it to do.  That's not a bug.

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.
It's treated as a FLAC file because the file suffix is .flac, not .lossy.flac.
Last Edit: July 29, 2018, 01:46:00 PM by frankz

rygle

  • Jr. Member
  • **
  • Posts: 22
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;
* https://hydrogenaud.io/index.php/topic,75992.msg670799.html#msg670799
* third post down referring to a Wiki article that is in the next link - http://forums.stevehoffman.tv/threads/lossywav-a-new-lossy-version-of-he-wav-format.148927/
* https://wiki.hydrogenaud.io/index.php?title=LossyWAV#File_identification
* https://hydrogenaud.io/index.php/topic,55522.msg498559.html#msg498559

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

Last Edit: July 29, 2018, 04:16:08 PM by rygle

supersonic

  • Jr. Member
  • **
  • Posts: 29
The problem comes from documentation (eg. https://wiki.hydrogenaud.io/index.php?title=LossyWAV#File_identification) calling it a double file extension when double file extensions (in Windows at least) don't exist, the .lossy part is just part of the regular filename and only added as an identifier that it was processed using lossyWAV and not losslessly as you would suspect a normal .flac file to have been. Also it will be the encoder adding it to the filename after MusicBee has given the encoder the filename (eg. *track* *Title*) to use, if you tried to rename it in Windows Explorer it would want to get rid of the .lossy part too.  

I understand why they do it but I personally thought it was a silly and messy way of adding an identifier of .lossy and calling a double file extension instead of using a more sensible way such as -lossy.flac because it is just a flac file and that way it wouldn't cause this type of confusion.

People rename their files all sorts for identification means, one of the links you gave mentions .mp3.lossy.flac as a triple file extension but there's no such thing it's only a .flac file with two custom identifiers so they know where it came from, it's like if someone puts .320.mp3, -VBR.mp3, [256].m4a or .lossless.flac, I personally prefer using folders to separate files than these type of filename identifiers.

Because of this I would say it's not a bug as MusicBee is doing what it thinks it should be doing, it's taking a potentially 'messy' filename and renaming and 'organising it', but it could be a Wishlist so if a file extension is immediately preceded by .lossy (especially if it's a .flac or .wav) then it should keep the .lossy in the filename.

frankz

  • Sr. Member
  • ****
  • Posts: 3834
The problem comes from documentation (eg. https://wiki.hydrogenaud.io/index.php?title=LossyWAV#File_identification) calling it a double file extension when double file extensions (in Windows at least) don't exist, the .lossy part is just part of the regular filename and only added as an identifier that it was processed using lossyWAV and not losslessly as you would suspect a normal .flac file to have been. Also it will be the encoder adding it to the filename after MusicBee has given the encoder the filename (eg. *track* *Title*) to use, if you tried to rename it in Windows Explorer it would want to get rid of the .lossy part too. 

But...but..."Double file extensions" are a real thing because Hyrdrogenaudio says so!!  Don't you know they create Windows file naming conventions over there now?  Microsoft calls them in their basement lairs to ask them how to handle things all the time. ;D

rygle

  • Jr. Member
  • **
  • Posts: 22
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 8.3.it 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?
Last Edit: July 30, 2018, 06:05:49 AM by rygle