-
-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Doesn't handle filenames with spaces in #22
Comments
Hello @pcolmer, thanks for bringing this up. I'll look into it. |
I believe
Calling
Are you interested in an |
Yes, please :) Thank you for taking the time to investigate If you are able to add an |
Hello @pcolmer, please check the latest pre-release and use the option |
Hello @crra Thank you for making this addition. There is something about the created output file that Windows Media Player doesn't like, unfortunately. I can play it with VLC though. Using
If I use the same tool on the (397) source files, they are all reported OK. I hope that helps. Please let me know if you need me to run anything else over the files. |
Do you have a file to share to analyze? |
I'm trying to use this tool in a way that it processes a list of files from a text file rather than allowing it to glob the directory or specifying the files individually within the command.
For example:
The reason for taking this approach is because some of my directories of files don't have them named correctly to respect the play order (e.g. they are missing leading zeroes on the track numbers). So I
ls
the directory to a file, edit the file to fix the order and then feed the list tomp3binder
.However, if the files have spaces in their names, it doesn't work. If I leave out
--lang "en-GB"
I get the errorprovided language 'C': unsupported language
. After I explicitly specify--lang
, the utility breaks on the first space in the first filename. I then try to work around that by gettingls
to put double-quotes around the filename:but it still breaks on the first space in the first filename. It doesn't look like the commandline parser is respecting (or looking for) double-quotes.
The text was updated successfully, but these errors were encountered: