Picard doesn't recognize some non-Latin characters?

MusicBrainz Picard
, ,
10

@SturmB I tested this again on an upt-to-date Windows 10 system, both with the registry key for long file support enabled and without. You might be able to work partially with long paths in Picard.

So in general you have three ways to load files into Picard:

  1. Via Add Files / Add Folders dialog: This actually works for me, no matter if long file format is enabled or not (1). So this might be a solution if you want to handle your files with Picard. But be aware that currently Picard is hard coded to shorten file paths to 260 characters if it renames files and generates folders.
  2. Via drag and drop from the integrated file browser. This is what you have done, and it results in the error you have posted. This does not work at all, no matter if long file name support is enabled. I did not know about this issue, but I will debug it.
  3. Via drag and drop from outside, e.g. from Explorer. Files dropped on Picard this way by default are not even recognized by Picard, Picard does not even notice something got dropped (2).

For case 3) however there is a way forward: If long path support is enabled in registry and the application manifest (picard.exe.manifest) also indicates long file support (3), then drag and drop also works. Which is great. Nope, unfortunately not true. In my test Explorer was actually passing the shortened DOS compatible file name for the long path (something like C:\Users\Developer\Music\LONGPA~1\WOLFGA~1\01-WOL~1.INT, another legacy thing Windows still handles), hence it worked. Tested on a different path where Explorer uses the \\?\ prefix and drag and drop does not work. So this needs to be handled separately.

I think going forward we should extend Picard in two ways:

  1. Extend the application manifest by default to indicate long file support
  2. If long path support is enabled in the registry on Windows 10 then don’t enforce the 260 character path limit. But maybe allow the user to enable it again. Not everybody wants to end with paths the Explorer cannot handle properly.
  3. Fix the issue with the internal file browser.
  4. We should also have a FAQ entry about enabling long file support.

Long paths issues are actually tracked in the following ticket:

(1) This is handled by special file paths: Windows at some time extended the classic Windows API so that file paths starting with the special character sequence “\?” can exceed the path limit. This really is kind of a hack, but it allows applications to access those paths. If you open a long path via the dialogs the application receives a path with this prefix (e.g. \\?\C:\A Very Long Path With More Than 260 Characters ...\Some File.mp3)
(2) This is because WIndows handles drag and drop differently in this case, and this is not supported by Qt5, the GUI library Picard uses. A manual implementation of this might be possible.
(3) See https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#enable-long-paths-in-windows-10-version-1607-and-later

5 Likes