DarwinAwardWinner / transfercoder

Transfer and transcode your music at the same time
9 stars 3 forks source link

File name restriction flags? #10

Open hynet-mel opened 7 months ago

hynet-mel commented 7 months ago

Hello, first of all, thanks for this program. It's been very useful for transfering music to my phone :D I did want to ask if by chance was possible to add a flag to substitute some special characters, or ommit them completely in the target directory. As I've noticed special characters like '?' and '!' just happen to get refused by the Android filesystem. I might see if I can PR this as a feature as well

DarwinAwardWinner commented 6 months ago

Hi,

I don't have a ton of spare bandwidth to work on this right now, but I'd be happy to look at a PR for this. However, note that solving this issue is non-trivial, because if you start modifying file names, you have to handle the case of two different file names mapping to the same destination, e.g. My Cool Song?.mp3 and My Cool Song!.mp3 would both be mapped to My Cool Song.mp3. Honestly, the better solution would probably be to scrub any problematic characters from file names in your music collection prior to running transfercoder.

As for implementation, I would add a new command-line option that takes a string containing all characters to be removed, and maybe a second one that takes a single character to use as a replacement. (If the 2nd option isn't provided, then the default is the empty string, i.e. just delete the characters and don't replace them with anything.)

By the way, I think the same non-unique destination problem actually already exists if the source FS is case-sensitive and the destination isn't.

hynet-mel commented 6 months ago

Hello

Honestly, the better solution would probably be to scrub any problematic characters from file names in your music collection prior to running transfercoder.

That's probably a better a approach indeed, cheers. I'll fix it for now that way.

As for implementation, I would add a new command-line option that takes a string containing all characters to be removed, and maybe a second one that takes a single character to use as a replacement. (If the 2nd option isn't provided, then the default is the empty string, i.e. just delete the characters and don't replace them with anything.)

That seems like a good approach to it, I'll see what I can come up with in a PR.. It could be a nice additional flags for filename manipulation for devices with filesystem limitations or case-insensitivity. Additionally some meta-flags like `--android or as presets could be nice, as well as flags (e.g.--upper` ) to potentially fix case-insensitivity. What do you think?

DarwinAwardWinner commented 6 months ago

I think having a preset flag would be good, although if possible there should be just one preset that works for all commonly used filesystems, allowing only the lowest common denominator set of characters. For case-insensitive, I would add a --case-fold option with arguments upper, lower, and none, with none as the default.

One important caveat to all of this is that any file name munging has to apply to only the component of the file name relative to the main destination folder. E.g. you could have a FAT32 filesystem mounted on a mount point that itself is not a valid FAT32 file name, and you would only want to munge the part of the file path that is on the FAT32 filesystem, not the part representing the mount point.

Also worth noting, Quod Libet's renaming feature has some other useful options for munging file names (see screenshot). If these features are made available as importable Python functions, they might be worth adding as well. If the number of options becomes too large, they should be "namespaced" by adding a common prefix, e.g. --dest-file-case-fold, --dest-file-remove-characters, etc.

Ultimately though, I don't know if I want this to get too complex. I still think pre-scrubbing file names is the most expedient solution, though I recognize that there's value in having "good" file names in the main collection and then only munging them worse on problematic filesystems.

image