fix: match audio extensions case-insensitively - #11
Open
Dhevenddra wants to merge 1 commit into
Open
Conversation
Path.suffix preserves case while the extension sets are lowercase, so .WAV and .MP3 files never matched. All three call sites fail quietly: - utils/file.py backs list_files, which builds the training set in data/datasets/vocoder.py, so uppercase audio was dropped from the dataset without a warning. - test.py dispatches inference on the suffix and ends in `else: continue`, so those files were skipped with no message and no output. - scripts/random_copy.py carried the same comparison. Lowercase before comparing, and in test.py read the lowered suffix in both branches so the two comparisons cannot drift apart.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Extensions are compared against
Path.suffix, which preserves case, while the extension sets are lowercase. Files written as.WAVor.MP3therefore never match. Recorders, phones and camera firmware produce those routinely.Three places are affected, and all three fail quietly:
utils/file.py:55feedslist_files, whichdata/datasets/vocoder.py:25uses to build the training set. Uppercase audio is dropped from the dataset with no warning, so a run trains on a smaller corpus than the user thinks.Reproduced against
mainon a directory of six files:After the change all five audio files are found and
skip.txtis still excluded.test.py:53and:73dispatch inference on the suffix, and the trailingelse: continuemeans an uppercase file is skipped without a message. Pointingtest.pyat a directory of.WAVfiles writes no output and reports no error.scripts/random_copy.py:18carries the same comparison.Fix
Lowercase before comparing.
list_filesalso lowercases the incoming set, so a caller passing{".WAV"}behaves the same. Intest.pythe suffix is lowered once and both branches read it, which keeps the two comparisons from drifting apart later.Nothing else changes: sorting, recursion, the extension sets and the returned
Pathobjects keep their behaviour, and each filename keeps its original case.Verification
The repository has no test suite, so rather than introduce a framework I verified with the directory reproduction above, run before and after the change.
black --check,isort --check-onlyandruffare clean on the changed files. Two pre-existing findings are unrelated and unchanged by this PR:ruffE721 inmodules/generators/refinegan.py:107, andcodespellflaggingfroinmodules/losses/stft.py:55, which is the Frobenius norm argument.Related
The same comparison exists in
fishaudio/audio-preprocess, where I opened PR #39 for it, and infish-speech's DAC inference entry point (PR #1313). Thelist_fileshelper looks to be shared lineage across the three repos.