Yeah, I think a manual fallback is best, I suppose it depends on how many cases of this there are. If there are relatively few, then manual fallback, otherwise some additional replacement rule.

Running into an issue where some filenames only consist of invalid characters in certain file systems. It triggers an unfixable non-compliant status since my ideal solution would be a prompt to input a file name. I was thinking about automatic substitutions of forbidden characters, but what happens in the case of a track like “******”? This is a real track name and wouldn’t work well if, for example, replacing an asterisk with a string.

+1 here. rsync that involves folders with band names like "Moxy-Früvous" fails and always recopies.

What tool can't read such a filename, out of interest?

Please consider adding this as a matter of some urgency. On macOS it's quite easy for Bliss to inadvertently create a folder or file with a name that means that it subsequently cannot be processed in any way, by any tool.

For example, the filename "Mötley Crüe" on an AFP mounted remote drive, served by Linux (as is common in home NAS devices, for example), cannot subsequently be opened, deleted, renamed, or moved by anything on macOS.

Luckily in this case I was able to use the NAS device's web interface to delete the offending folder, although of course it came straight back again the next time I backed up my music collection to that device.

Providing a way to limit Bliss to the basic 127-bit ASCII character set for all filename & path elements would be ideal in my situation, with conversions from accented characters to their unaccented equivalents in all cases e.g. "Mötley Crüe" → "Motley Crue".

Agreed. Remember, though, that a lot of the use cases for bliss are working around companies not stepping up for various reasons ;-)

Oops, mistyped - I meant OS proscribed characters :)

It wasn't immediately clear to me that you were only taking on board the special characters (of which windows has far too many, but that is another discussion) rather than considering purging accented characters which I think was the original thrust of this request. UFT-8 has to be the way to go and other software packages should step up to it rather than damaging international support by attempting the horrible task of filtering out accented character.

They were asking for both - I was answering the special character case. We already support UTF-8. What do you mean by "OS prescribed symbols"? Are you saying there are characters from the non-Latin set that aren't permitted? If so, please send me a URL!

Replacing special characters which cause the filesystem to glitch is one thing and is probably an unfortunate necessity due to the way Windoze works, but the OP was asking for umlauts and diacriticals to also be removed. These are not special characters to many non-English speakers, but an integral part of their language. The correct solution is to support UTF-8 and filter only OS-prescribed symbols. Most browsers and major software packages can already handle UTF-8 so the support infrastructure is already in place.

For the record, I am English and have no need for accented characters except when being anal about loan-words, but we really need to avoid the sort of linguistic imperialism which tells others that they don't need part of their alphabet.

Yeah, that could be another idea: specify replacement character for file system sensitive characters.

The list of disallowed characters in bliss is the one here: http://msdn.microsoft.com/en-gb/library/windows/desktop/aa365247(v=vs.85).aspx

But I think this idea is about expanding this to cover other characters?

Hi Dan,

theoretically, the option that controls Ripit's replacement behaviour for special character is [chars], which will identify characters that Ripit will purge from the filenames but not the Tags. Regardless of the setting, the following character will always be removed:

; > < " and \015

At least on my standard Vortexbox install [chars] is set as follows

chars=NTFS

which would result in these additional removed characters

| \ : * ? $

What I found to be the case on my system (and I haven't seen anything about it in the Ripit documentation yet) is, that any / will be replaced by -
So songs that have multiple names in one track like "something / something else" will become "something - something else", while Bliss thinks those should me removed as well: "something something else"

What are the character replacements in ripit... does anyone know?

I strongly support this feature request as well. When ripping with ripit on a Vortexbox often the character replacement that bliss expects is different from the one that ripit does resulting in wrong file name detections in bliss.

I want to strongly support this feature request. It's not just a matter of compatibility with different operating systems but must importantly a matter of making your songs compatible with MusicIP. If I'm not mistaken, MusicIP (and hence also Spicefly Sugarcube) will not work with songs that have non-ascii characters in their path. Since MusicIP is no longer developed, the only way to fix this is by not using umlauts etc. Bliss could do an excellent job to fix that.

or maybe make it remove and special characters all together as an option

I would also like to see this, i have had lots of troubles with just apostrophes getting viewed as a question mark or a dash getting changed to a question mark

I need something along the same lines. Some band names and song titles contain characters that cannot be used in Windows file systems, such as "/" and "?". Currently, bliss deletes any character it doesn't understand from the filename. I would like to see bliss let me tell it through a list to replace invalid characters with a consistent valid one of my choosing.