I have a little programming experience but am completely new to shell scripting.

I have several hundred mp3s which I want to split using mp3splt with the command

mp3splt -A XXX.txt XXX.mp3

I have run this command by hand in the past but now have a project where doing it by hand would be impractical due to the number of files. In my imagination it should be easy to write a script that searches a folder for all the mp3s that have a txt file of the same name and runs the above command on them.

My question just is this: Is there any obvious reason this would not work? If you (meaning: a person with experience in shell scripting) don´t see any such reason, I´d work my way through this tutorial to work out the rest. If, on the other hand, you say it is impossible, I can just stop and do it by hand.

Thanks in advance!

In case you are interested in my use case: I play irish music, which is based on short melodies played by heart. I want to learn these melodies using anki with audio files. For that, I need to have audio files with just one specific tune each.

  • DollyDuller
    link
    fedilink
    English
    arrow-up
    10
    arrow-down
    1
    ·
    edit-2
    2 days ago
    find /your/mp3/directory -type f -name "*.mp3" -exec test -f "/your/mp3/directory/$(basename -s .mp3 {}).txt" \; -exec mp3splt -A "/your/mp3/directory/$(basename -s .mp3 {}).txt" {} \;
    

    This one liner should still work, even if your file names have spaces in them because find now looks at each individual match, not the entire output. Using a for loop with the results of find would create a lot of extra pieces of the file names because spaces separate the arguments. However, this single command is harder to read than using a for loop.

    The idea behind this one is that search operators in find evaluate to true or false. The first exec tells find to run the second exec only if the file exists. If the file doesn’t exist, it just ignores it.

    • sjohannes
      link
      fedilink
      English
      arrow-up
      4
      ·
      1 day ago

      I don’t think that works, because the command substitution in "$(…).txt" runs immediately in the current shell.

      Aside from that, find -exec doesn’t use a shell to run its command, which means $(…) won’t work without an explicit sh call.

      I believe the right command in this style that will work is:

      find /my/mp3dir -type f -iname '*.mp3' -exec sh -c \
        'test -f "${0%.mp3}.txt" && mp3splt -A "${0%.mp3}.txt" "$0"' \
        '{}' ';'
      

      However, I would recommend the for f in *.mp3-style solution instead, as to me it’s more readable. (The Bash/Zsh recursive glob (**) syntax can be used if subdirectories are involved.)

      • DollyDuller
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        1 day ago

        You’re correct about command substitutions, the $(...) part. I had initially thought putting it inside a sh would be clearer and avoid problems with substitutions. However, $0 is the name of the shell or the script. To fix this, we can put {} inside a variable, like this: file="{}". Then, we can use the variable $file for the rest of the command.

        I also think using for loops makes the command easier to read. But dealing with files that have spaces in their names can be really frustrating when you use for loops.

    • stewie410
      link
      fedilink
      English
      arrow-up
      1
      ·
      2 days ago

      Huh, I hadn’t realized you could chain -exec statements in this way; I assumed \; or {} + had to be the end of the arguments.

    • shrugs@lemmy.world
      link
      fedilink
      English
      arrow-up
      2
      arrow-down
      1
      ·
      2 days ago

      Nice one. Doing for loops with a list of files is a common mistake. I hate the exec syntax of find though. Why the fuck do we need ; at the end

      • DollyDuller
        link
        fedilink
        English
        arrow-up
        2
        ·
        2 days ago

        This helps distinguish commands that find runs from its own arguments. Imagine how find would figure out which commands it’s executing, and what their arguments are. The easiest way to do this is to use the standard end-of-command character. That way, you don’t need to create a special way to separate things. You can even put one find command inside another.

  • Kissaki
    link
    fedilink
    English
    arrow-up
    6
    ·
    2 days ago

    You linked a tutorial to sh. Note that nobody ends up shell scripting in sh. People will use bash, which is an alternative shell and shell language, and almost universally available where sh is available. sh is very old and limited. bash is much more common.

    There’s many other kinds of shells as well though. And you such an automation task you could use any number of scripting languages. The part that makes it a shell, which is interactive use, is not necessary for a scripting task like this of automating an operation. Shell languages can be used as scripting languages too though. I just want to point out alternatives and context.

    Personally, I use Nushell as my daily shell and for scripts and am very satisfied with it. It’s not universally available as in pre-installed, but is multi-platform and easy to install through an exe or package. Because it’s a newer project, there’s not that many resources yet, and still occasionally makes changes to its language with new releases. But, for me, the upsides to other shells are obvious and significant. I posted my Nushell solution in a separate comment (separating concise solution from this general prose exploration).

  • Kissaki
    link
    fedilink
    English
    arrow-up
    4
    ·
    2 days ago

    My preferred shell is Nushell. I would write:

    glob **/*.mp3 | wrap mp3 | insert txt { $in.mp3 | path parse | update extension 'txt' | path join } | each { ^mp3splt -A $in.txt $in.mp3 }
    

    or with line breaks for readability

    glob **/*.mp3
      | wrap mp3
      | insert txt { $in.mp3 | path parse | update extension 'txt' | path join }
      | each { ^mp3splt -A $in.txt $in.mp3 }
    
    1. glob to find the files (according to pattern from current dir)
    2. wrap list values in a named column
    3. add column txt with extension replaced by txt
    4. => now I have a table with mp3 and txt columns with respective full paths
    5. call mp3splt for each
  • TootSweet@lemmy.world
    link
    fedilink
    English
    arrow-up
    4
    ·
    edit-2
    2 days ago
    #!/bin/bash
    
    set -e
    
    find /path/to/parent/directory/of/mp3/files -iname '*.mp3' | while read m ; do
      t="$(basename "${m}" '.mp3')"
      [ -f "${t}" ] && mp3splt -A "${t}" "${m}"
    done
    

    Something like that?

    I’d definitely encourage you to study and understand it so you know basically what it’s doing, but it should be roughly in the direction of what you’re describing.

  • sin_free_for_00_days@sopuli.xyz
    link
    fedilink
    English
    arrow-up
    4
    ·
    edit-2
    2 days ago

    I have no idea how mp3split works, but this might help. If it fails gracefully, you could just do something like

    for mp3file in *mp3; do
        textfile="$(mp3file%.*}.txt"
        mp3split -A "$textfile" "$mp3file"
    done
    

    If it doesn’t fail gracefully, you’ll just have to put a test in there before the mp3split. Something like (this is untested, off the top of my head. May not work, but it should give you an idea):

    for mp3file in *mp3; do
        textfile="$(mp3file%.*}.txt"
        if [ -f "$textfile" ]; then
           mp3split -A "$textfile" "$mp3file"
        fi
    done
    
  • 𞋴𝛂𝛋𝛆@lemmy.world
    link
    fedilink
    English
    arrow-up
    2
    ·
    2 days ago

    Depending on the file size, but with most of this kind of thing, I copy all the stuff to a /tmp directory first. Then you can’t screw up the main files, and it will all get removed after reboot so you can’t leave a mess in a directory somewhere you forget to clean up when you’re done.