Find referenced sample files ignoring the upper/lower case (#342)

[douglas-carmichael]

Fixes #342.

Sampler file systems are case-insensitive and their CD-ROMs store all names in upper case, but a preset may reference them in lower case - or the other way round. On a case-sensitive file system, which is the normal case on Linux, none of those samples are found:

Analyzing: /tmp/Strings/STEREO STRS2.AKP
Detected Akai Preset (S5000/S6000).
Sample file does not exist: /tmp/Strings/STR SEC.6 -L.wav
Sample file does not exist: /tmp/Strings/STR SEC.6 -R.wav

The reporter guessed that other formats are affected as well, and they are - 10 places in 7 format families build the path themselves and then only check exists (). Two of them fail the other way round, because they hard-code the upper case ending.

The fix

AbstractDetector.findFileIgnoreCase returns the exact file if it exists, otherwise a sibling whose name only differs in its case, otherwise the requested - non-existing - file. That last part keeps every caller reporting a missing file exactly as before, so the change is a drop-in replacement for new File (folder, name) at each site. On a case-insensitive file system the exact match always hits, so the directory is never even read there.

Detectors which built the path themselves:

Detector	Was hard-coded
Akai AKP - sample lookup	.wav
Akai AKP - AKM program lookup	.AKP
Akai MESA	.wav
Akai MPC modern (2 places)	.WAV, so it failed on lower case
Akai MPC1000	manual .wav/.WAV fallback, replaced
FL Studio DirectWave	name used as-is
Teenage Engineering OP-XY	name used as-is
Synclavier Regen	name used as-is

The common search in findFile needed it too: getCaseVariants only flips the file ending when it is already all upper or all lower case, so a mixed case ending or a base name differing in case was still not found. It now falls back to the case-insensitive lookup, and findFileRecursively uses it as well. That covers the Ableton, Deluge, EXS24, Kontakt, Maschine, 1010music, SXT and TX16Wx detectors.

Tonverk already did this with its own findTolerant and is unchanged.

Verification

macOS is case-insensitive, so the bug cannot reproduce on it. I created a case-sensitive APFS volume and ran everything against both a stock build of main and this branch.

There was no AKP file to be had here, so I generated one from the offsets in AkpFile/AkpKeygroup and gave it the sample names from the report. It reproduces the reported output on main, and on this branch:

Analyzing: /Volumes/CWMCASE/akp/Strings/STEREO STRS2.akp
Detected Akai Preset (Z4/Z8).
Analyze: 'STEREO STRS2' OK

A full conversion writes both samples. Two more end-to-end cases on the same volume:

• Akai MPC modern, samples renamed to lower case: main reports 3 files it could not find, this branch converts all 3.
• Deluge through the common search, sample names in all upper case: main reports "The file does not references any samples", this branch finds all 3. This is the case getCaseVariants cannot handle, since the base name differs too.

No regression on a case-insensitive file system: reading SFZ, Deluge, OP-XY, Bitwig and DecentSampler presets and converting them produces byte-identical output on both builds.

One caveat on the test corpus, for whoever repeats this: the brute-force upward search in findFile happily finds an identically named sample in a neighbouring test folder and reports success, so each case needs unique sample names to mean anything.