I woke up this morning and wanted my music, so I changed the rechargeable AAA batteries in my Zoom F1 and got it playing on my portable soundbar. All was great until it encounter another "invalid File" and stopped playback. The point of using this device for music playback is uninterrupted playback. It's quite jarring to have a song end and unlimited silence follow. Especially when working on something that cannot be set aside, such as a weld in progress.

I've taken note of 2 offending files and found a pattern in them: 320kbps mp3 files. The original script to convert the audio files for the Zoom was set up to skip mp3 files as I was unaware of this limitation. I confirmed that the offending file works when taken down to 192kbps, but I want the highest that it will support. I suspect it will handle 256kbps just fine, as I compared a known working file and seem to remember seeing that bitrate. I've rewritten much of the original script to not only convert all mp3 files to 256kbps mp3, but also to change the file extension to MP3, with capitals, as ffmpeg would not "edit a file in place" when trying to specify the same file name. This works for me as I can tell the files apart quickly, and sort by converted and unconverted. I also specified a different output folder for the script so that I can keep the files separate.

Currently, I am writing simple instructions inside the Zoom_Converter.sh program to make it a little easier to figure out. It already has a "source" variable, and I will add in a "destination" variable when I get a chance. The end goal is to have a simple GUI program that will run on any system, and just automatically prepare any audio files for use on the Zoom F1. This would include shuffling the files if desired, converting them, then batch renaming and exporting to the specified SD card. Another feature I'd like to add is an auto shuffle feature where you can just have it re-order and rename the files to change up the music playlist. I will likely write this program in Python, using tkinter for the GUI as I am already familiar with both, and they are fairly standard. I may compile some executables for various systems if I can decide on a good system for that and get it working. I understand that many people who already own this device may not be programmers, or even use Linux. The goal is to turn one of the best pieces of compact audio gear into a suitable music player in its free time. Ultimately, I want to hack the firmware and write custom firmware for it to turn it into a full featured recorder and player. I do not have anywhere near the skill for that at this time, so I must work within the limitations of a stock device.

Another limitation I've found is the speed at which the device skips files. It is very slow to skip through files, meaning it takes quite a while to get to the song you want. This is a minor complaint as I just let it play all day long as I work.

A more serious issue I've run into is the fact that ffmpeg is only using a single core to do the conversion. This isn't a serious issue for most people, but I work from a Raspberry Pi 400 these days, and it can be painfully slow at times, especially with 3 CPU cores sitting nearly idle. I could look into making a multi-threaded program, but it isn't that simple. I suspect that the core issue is that fffmpeg can only work on one file at a time, so I would need to open a new instance for each CPU core, and specify a file for that instance. I haven't thought of this before, but I suspect I could add it later down the road when I implement this is program in Python. I'm sure there is an accepted best approach to this, but I like to try to figure it out myself first and see how close I get to the "right" answer. My first thought is to have the program count the number of physical CPU cores, subtract 1, then use that as the number of instances to run. I'd leave 1 or 2 cores unused as to not bog down the entire system. The user could also specify the number of cores to use. I think the easiest way to divide the workload would be to just have an instance grab the next available file from the list, then mark it "in progress" then "done" somehow to have it taken out of the queue. My other thought was to divide the total number of files by the number of available cores, but this could leave idle instances when one finishes a batch of small files faster than the others. picking from one pile seems to be the more efficient method.

At this time, the process is far easier than it was, having updated the script and put the shell commands into the comments of the file. I also standardized the process  and am skipping a few extra steps by exporting the files directly to the SD card instead of an intermediate folder. I found that Krename has a "random" sort feature when adding files, that solves one of my biggest problems. I wasn't sure how to shuffle the files at first. I was going to write a program to do it until I discovered this feature.

Overall, I am very happy with the Zoom F1 as an mp3 player, and will continue to streamline the process and see what it's capable of. I will upload the new and improved script soon, in case anyone cares to use it. It's a general audio converter, so has uses outside of what I am doing here.