Skip to content
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

Closed
pcolmer opened this issue Aug 28, 2022 · 7 comments
Closed

Doesn't handle filenames with spaces in #22

pcolmer opened this issue Aug 28, 2022 · 7 comments
Labels
enhancement New feature or request

Comments

@pcolmer
Copy link

pcolmer commented Aug 28, 2022

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:

ls *.mp3 > list.txt
FILELIST=$(xargs -d "\n" -a list.txt ls);  mp3binder $FILELIST --lang "en-GB" --output ~/tmp.mp3

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 to mp3binder.

However, if the files have spaces in their names, it doesn't work. If I leave out --lang "en-GB" I get the error provided 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 getting ls to put double-quotes around the filename:

FILELIST=$(xargs -d "\n" -a list.txt ls --quoting-style=c); mp3binder $FILELIST --lang "en-GB" --output ~/tmp.mp3

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.

@crra
Copy link
Owner

crra commented Aug 28, 2022

Hello @pcolmer,

thanks for bringing this up. I'll look into it.

@crra
Copy link
Owner

crra commented Aug 28, 2022

I believe xargs messes thing up. I'm using this simple bash script to see what xargs provides:

i=1;
for arg in "$@"
do
    echo "Arg - $i: $arg";
    i=$((i + 1));
done

Calling xargs the way you provided results in:

FILELIST=$(xargs -d "\n" -a list.txt ls --quoting-style=c); ./foo.sh $FILELIST
Arg - 1: "
Arg - 2: sample2.mp3"
Arg - 3: "sample
Arg - 4: 1.mp3"
Arg - 5: "sample.
Arg - 6: 4.mp3"
Arg - 7: "silence
Arg - 8: copy.mp3"

Are you interested in an --input option where you could provide the file directly?

@pcolmer
Copy link
Author

pcolmer commented Aug 28, 2022

Are you interested in an --input option where you could provide the file directly?

Yes, please :)

Thank you for taking the time to investigate xargs and its behaviour.

If you are able to add an --input option, that would be much appreciated!

@crra
Copy link
Owner

crra commented Aug 28, 2022

Hello @pcolmer,

please check the latest pre-release and use the option --input. There is no need to quote each line, but keep in mind that leading and tailing white spaces will be respected.

@crra crra added the enhancement New feature or request label Aug 28, 2022
@pcolmer
Copy link
Author

pcolmer commented Aug 29, 2022

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 mpck (https://github.com/Sjord/checkmate) on the built file, it reports the following:

SUMMARY: foo.mp3
    version                       MPEG v1.0
    layer                         3
    average bitrate               -21743 bps (VBR)
    samplerate                    44100 Hz
    frames                        2020051
    time                          -743:-42.-869
    unidentified                  886 b (0%)
    errors                        unidentified bytes
                                  inconsistent frame headers
                                  invalid header values
    result                        Bad

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.

@crra
Copy link
Owner

crra commented Aug 29, 2022

Do you have a file to share to analyze?

@crra
Copy link
Owner

crra commented Aug 30, 2022

@pcolmer I've moved the problem with the corrupt output file to a new issue (#23) so that we can close this one (different scope).

@crra crra closed this as completed Aug 30, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants