SUMMARY K3b appears to be Windows-centric. When ripping audio tracks, such as digitizing years-old cds before bit-rot sends it to the ddrescue queue, linux folk have to change the target folder for each disc, then edit the File Naming tab to eliminate spaces from the patterns, the check Replace all blanks. Postproduction requires deleting commas, colons, semicolons, and unprintable chars from the filenames, none of which may not be necessary on windows boxen. STEPS TO REPRODUCE 1. Start Ripping OBSERVED RESULT Need to change target Target Folder, since K3b ignores the temporary folder in settings, remove each space from the Ripped-files and Playlist patterns, and Replace all blanks with underscores. Post production requires a sed script to remove commas, colons, semicolons, unprintable characters, and all to prevent File-Not-Found errors on a command-line interface. EXPECTED RESULT An option in Settings to choose filenames with no spaces, escape the special chars that the bash shell uses, and a default target directory instead of just tossing everything into the $HOME directory. In addition, should be able to set the default ripping filetype, since not everyone wants compression and Copy Medium is broken. [Workaround - cajole the coders into compliance with the Law of Least Astonishment or use ffmpeg concatenate to create a single wav file from all of the Track.wav files using the filename of the tracks directory .] SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Plasma Version: 5.27.11 KDE Frameworks Version: 5.115.0 Qt Version: 5.15.13 ADDITIONAL INFORMATION Wayland
spaces are allowed in windows and in linux. I am hoping to help keep filenames confirming to rules of as many systems as practical/reasonable. Windows/Mac/Linux... There are many variations in all of that that I am not familiar with, but I would want to limit the path to 256 characters, and typeable characters, no emojis, no escape characters... where /and \ are only used for directory
I looked at the relevant code. This problem lies with the CDDB database. It appears that the db is sullied by children misusing Windows submissions: full of spaces, apostrophes, parentheses, semicolons, commas, mixed case, different languages and all. This would be a monster task to impose standards-compliancy upon the existing entries, not so much for new entries after the screens are in place. A few sed and tr statements in the get-cddb functions would fix it, but violations of file-naming standards is in cddb.org, not K3b. Since it is relatively easy for me to fix the mess in post-processing, this is not a bug. Who knows who enforces international file-naming standards. Me, I'm more focused upon 'works only in Windows' webbage, making folks aware of https://validator.w3.org and http://www.anybrowser.org/campaign when I can no longer log in to pay my bills because some moron hired a code jockey who is capable only of manipulating a Windows html-design gooey.