Mp3splt is an old but pretty nice console utility for splitting MP3 files without re-encoding them (it can apparently handle a few other types as well). I'm working on a project that makes use of it to batch-trim extra silence from the beginning and end of MP3s and one of the long-time gripes i've had with Mp3splt is that it adds "_trimmed" to the output file names by default. Not being the sharpest knife in the drawer, it took me a long bloody time to FINALLY figure out how to eliminate that. I'm disclosing my solution here with the hope that someone else benefits since i never found a solution anywhere else.
, the clues are all there, primarily with the
options, but what complicated matters for me what that i wanted to run Mp3splt in a directory above the MP3s which would be dumped first in
and then in
and i wanted to do it without using
in my script.
Here's what worked for me:
is eliminated, then Mp3split creates the
directory in the
directory which is just plain strange i think. Anyway, the
will cause Mp3splt to retain the original file name.
One of the other gripes i had with Mp3splt is that, in some cases, it will keep trimming "silence" that isn't silence from an MP3 every time you run it on the same file, thus the file size will keep getting smaller and smaller and you lose a little more audio each time. The
seems to prevent that. When Mp3splt is used in trim mode (
), the value of
is the amount of silence in seconds that must be detected before trimming occurs. It is also the the amount of silence that will be retained at the beginning and end of the MP3. This value can of course be changed to whatever you want, but obviously Mp3splt cannot add silence.
Muzik Faktry is under heavy development. Documentation is not complete and may not be not accurate.
Apparently i'm an oddball because my music files usually contain only the artist, title and genre tags (and i only use 3 or 4 of the latter), along with the other required stuff. I'm not interested in embedding lyrics, images or whatever else people are sticking in their music these days. I like to aim for minimal, compact, error-free files that meet my medium-high quality standard and that's why we're here. If you're an audiophile geek with multiple ex-wives who spends weeks deciding which DAC will provide the truest sound, this might not be for you, but if you just like to listen to good sounding music while you prune your hedges, read on.
Typically i acquire specific songs from various artists rather than entire albums, mainly because i've yet to run across an album for which i like every song. The problem with this disjointed approach is that it results in consistency problems regarding tags, headers, volume, file names, etc.. Most maddening is when some aspiring government employee thinks that transcoding a 64 kbit/s MP3 to FLAC is somehow a good idea. With the exception of the latter, most issues are generally easy to fix using a few software tools.
Enter Muzik Faktry, a Bash shell script which is essentially a wrapper that handles various 3rd party tools and does so without relying on stuff i don't like relying on, such as Java, Wine, Mono or Electron.
Muzik Faktry is a menu driven script that runs in a terminal, but don't let that scare you to death if you're not a terminal freak... get it? There are plenty of prompts to guide you along and it presents a unified interface for running several software tools which are available for Linux-based operating systems (because they suck less than Windows operating systems).
Muzik Faktry was originally named MP3 Factory because i had originally been focused largely on producing high quality MP3s until i learned more about what a scrambled mess the MP3 format is. As a result i began to focus on the lossless FLAC format which is far superior. All of the tasks that Muzik Faktry performs are thus lossless, meaning there is no reduction in audio quality.
Muzik Faktry is intended primarily for transcoding (converting) uncompressed tracks or albums to the FLAC format and/or performing various operations on them before adding them to your collection, including comprehensive integrity checking. So comprehensive in fact, that when i first ran my music collection through it, the bloody thing flagged every single file as 'junk'!
The script may not be a complete solution for processing your music since it offers only rudimentary tagging functions, nor is it a complete replacement for comprehensive audio analysis tools, however it has served my needs quite well without having to employ any additional tools.
Muzik Faktry was developed and tested on Manjaro Linux or, as i affectionately call it, Arch for dummies, however it should run on any flavor of Linux that includes a Bash compatible shell and for which the dependent packages are available.
Collect metadata from many formats including FLAC, MP3 and WAV files
Batch processing and tagging
Splitting album files
Find duplicate files using several methods
Convert between FLAC and WAV formats
Write tags to file names and file names to tags
Write Vorbis tags to FLAC files
Save reusable metadata
Format file names
Repair and optimize files
Integrity and metadata checking
Generate frequency spectrograms for graphic analysis
Normalize gain (volume) with ReplayGain information
Tons of configuration options and multiple configuration files
The code is ShellCheck and Shellharden compliant, however that certainly doesn't mean it's bullet-proof so if when you find a bug, let me know
ffmpeg : "A complete, cross-platform solution to record, convert and stream audio and video." This package is installed by default with most mainstream Linux distributions.
flac : For processing FLAC files. This package is installed by default with most mainstream Linux distributions.
mediainfo (CLI version) : "A convenient unified display of the most relevant technical and tag data for video and audio files."
shntool : "... a multi-purpose WAVE data processing and reporting utility."
notify-send : Provided by the libnotify package, it is used to send desktop notifications to notify you when a batch process has completed. This package is installed by default with most mainstream Linux distributions.
shellcheck : "Finds bugs in your shell scripts". It is strongly suggested to install this package so that the configuration files for Muzik Faktry can be checked for syntax errors.
wget : Used to check for updates. This package is installed by default with most mainstream Linux distributions.
download and installation
DISCLAIMER: Muzik Faktry has not yet reached a stable release. It may not be feature complete and some stuff may simply be busted. If you choose to use it you should be smart enough to work on copies of your music files. If anything explodes, a mirror will reveal who's to blame :)
Having said that, i am developing and using it on my daily driver box without any guardrails. Then again, i've been known to do stupid things that result in catastrophe, like that time i formatted the wrong partition without first making a fresh backup (i never even thought to ask the NSA to send me their copy!).
You can download the Muzik Faktry files from Codeberg (direct links below). After downloading the archive, extract it somewhere where you have read, write and execute permissions, such as in your home directory. The muzikfaktry.sh script will be contained in a folder named 'muzikfaktry'. You didn't anticipate such stunning creativity, did you! Don't forget to make the script executable (
$ chmod +x muzikfaktry.sh
The configuration for Muzik Faktry is somewhat biased toward my particular needs rather than for general consumption so you'll probably want to fiddle with the settings.
You can create multiple configuration files in the /config folder in which case the script will ask which one you want to load when you run it. The suggested way to do this is to copy the default.conf file and give the copy a new and descriptive name and a '.conf' extension. If no configuration file is available then you're stuck with the default settings.
Run the script by opening a terminal, navigating to the 'muzikfaktry' folder, and running
. The script will run some checks to make sure its dependencies are met and then create some files and folders after which it's ready to use. No operations will be performed on your files without your explicit input and all important operations are logged.
During the course of running tasks you will be asked questions and given choices such as 'Press [Y] to do this or [N] to not do this. [Y/n]'. The default choice is indicated by the upper case letter in the brackets and can be selected either by pressing the letter, 'y' for 'yes' in this instance, or 'Enter'/'Return', or most any other key except 'n'.
While the order of the tasks in the Muzik Faktry main menu may seem odd, there are logical reasons for it. When performing multiple tasks they should generally be performed in order, though there are exceptions. For example, one probably wouldn't want to run the Strip Metadata task before writing a correct file name based on the metadata that will be forever lost after running this task. Similarly, it's probably pointless to invoke most tasks following the first Integrity Check task before an Integrity Check has been performed.
It is largely the Integrity Check and Metadata Check tasks that determines whether a file should be retained or discarded. As the names imply, these tasks check the integrity of many critical and not so critical aspects of your files.
To begin using the script, copy the files you want to process to the /working folder and from the main menu of Muzik Faktry, select a task to perform. The alert person you are, you noticed immediately that i used the word "copy" and not "move and potentially f'up all of your irreplaceable music files", right? Always work with copies of your files rather than the originals!
While you can work with multiple file types at once, i would suggest working with a single file type at a time in order to avoid confusion. If you do choose to process multiple file types then only the file types which are compatible with the chosen task will be processed.
If you choose to enable batch processing then Muzik Faktry will happily process all files in the /working directory that are compatible with the chosen task. In this mode of operation files are automatically retained or junked (moved to the /discarded folder) depending upon the integrity of the files and your configuration settings. If you're just getting to know Muzik Faktry then i suggest/warn/demand you avoid batch processing until you become familiar with how the script operates given your configuration choices.
After processing a file there may be one or more error messages. You always have the option to override any errors and keep the file as long as you're not operating in batch mode. Files with trivial problems, such as missing metadata, excess metadata, goofy file names, etc., are easily repaired by running another task.
Files with errors, trivial or otherwise, will have a semi-descriptive error tag prepended to the file name. The prefix will be automatically removed if the error is repaired and it passes a Metadata Check.
The spectral analysis, while somewhat time consuming, can be important in determining the quality of a file. I'm using mostly MP3's in the following examples, but this information can be applied to lossless formats as well.
One of the things to look for in these images is the frequency cutoff point, meaning the highest frequency the audio attains. Using the MP3 format as an example, the highest frequency that can be encoded is limited by the bit rate, however there is more to consider. Pictures are worth stuff they say, so let's give that a shot...
Here's what the frequency spectrum looks like for a random FLAC music file that indicated a bitrate of 872 kbit/s. The keen observer you are, you'll notice that the frequency cutoff is close to 21000 Hz, or 21 kHz, which is slightly higher than the highest frequency which the average young human is capable of hearing (~20 kHz). The file size here is a whopping 26,924,696 bytes.
Next i transcoded the 872 kbit/s FLAC file to a 320 kbit/s CBR MP3 (not something i would normally do). The file size dropped to 9,882,876 bytes, less than half of what it was. You'll notice the frequency cutoff point has dropped to around 20000 Hz, or 20 kHz, so while certainly lost the higher frequencies, we didn't lose anything that anybody without extremely good hearing and who is listening in a very quiet environment with a very decent sound system is likely to notice. We also saved a hell of a lot of disk space which may be worthwhile if you need to cram as many songs as possible onto that microscopic SD card that you struggle to plug in to your fondleslab.
Next i converted the 872 kbit/s FLAC to a 128 kbit/s MP3. This time the quality loss is significant to the point where many people with decent hearing in a quiet listening environment and a decent sound system would probably notice. If you're listening to music while operating a jackhammer however, then a 128 kbit/s might be just dandy. Here the frequency cutoff is around 16000 Hz, or 16 kHz, and the file size is 3,953,289 bytes, again half of what it was.
Now it's time to 'do as stoopid does'; i took the 128 kbit/s MP3 and upsampled it to a 320 kbit/s MP3 because "more quality", however the only thing i actually accomplished was to fatten the file size, which has now more than doubled to 9,882,876 bytes, the same size of the 320 kbit/s MP3 that was converted from FLAC earlier. The quality is, at best, no better than the 128 kbit/s file and the frequency cutoff point hasn't changed. The lesson here is that you cannot add quality to an audio file that doesn't have it in the first place!
So now we know that files with a high bit rate and a low frequency cutoff point are upsampled junk, right? Well, no. Not necessarily.
When encoding an MP3, audio data is sacrificed in order to reduce the file size, however the way that a good encoder (LAME) does this is to discard sound that the ear would probably never hear anyway, thus everything above a given frequency as well as everything below a given frequency is discarded right off the bat, but there's allot more to it than that. The bit rate is a primary factor regarding sound quality and frequency cut-off with the LAME encoder and as the bit rate is decreased, so too is the maximum frequency that the audio is able to attain. We know that the average young human with really good hearing can hear frequencies up to about 20 kHz, but as we age that threshold drops. Below is the approximate maximum frequency that can be attained at a given bit rate for a LAME encoded MP3. Keep this in mind when viewing spectrogram images of your audio files:
64 kbit/s = ~11 kHz frequency cut-off
128 kbit/s = ~16 kHz frequency cut-off
192 kbit/s = ~19 kHz frequency cut-off
320 kbit/s = ~20 kHz frequency cut-off
But again, the frequency cut-off point is not in itself a determining factor of audio quality. While the cut-off points above are useful for Rock and Pop type genres with a variety of instruments and vocals, they may be meaningless for songs which are not composed with so much diversity. For example, a 'perfect' quality audio recording of a flute, a vocal, or a piano, may have a frequency cut-off point that is well below 20 kHz.
Another thing to look for in the spectrogram is signs of clipping. Clipping is the result of the gain (volume) having been raised too high and this can lead to really nasty distortion when listening to the song. This is not uncommon given the loudness war we've been subjected to, as well as poor encoding practices. Here's a frequency spectrum of Acoustic Alchemy - Clear Air For Miles.mp3 (320 kbit/s CBR 44.1 KHz). There are no significant signs of clipping:
Using MP3gain i then increased the gain by 10 dB and this was the result:
What you'll notice is that a lot of the green and blue stuff now reaches the upper frequency cutoff point and this is indicative of clipping. Also see the Clipping or distortion section of the article Understanding Spectrograms.
Here are a few things to look for in a spectral analysis
Each format has it's own rolloff: CD drops like a rock at 20 kHz and MP3 drops steeply at 16 kHz. If you have a 96 kHz file with these sharp drop offs, it's likely been up-sampled.
Inspect the content above 20 kHz. If there is random "noise like" features in there, it's probably genuine. If it has very little content and/or the content looks like a low-pass filtered mirror image of the content below 20 kHz, it's been up-sampled.
You can look at correlation at high frequencies. For a genuine recording this will mostly be uncorrelated. If there is significant correlation, it's a potential sign of "joint stereo coding" which could hint at lossy compression.
Look at the recording date: If it's been made before 1990 it's almost guaranteed to be up-sampled. There never was a digital studio master and the best they can do is to sample a tape master.
So how do you use all this information? Well, this is where it gets tricky because a file that was encoded using a high bit rate, yet doesn't approach 20 kHz, is not necessarily junk. Given the wide variety of sounds in most Rock, Pop and some other genres of music we might listen to however, such songs will often approach or exceed 20 kHz as long as a lossless or high quality lossy encoding method was used.
Over time you'll develop a sense of what the frequency spectrum should look like given the bit rate and the different sounds present in the recording. Ultimately what matters however is whether you're happy with what you hear, not the fancy colors on a graph.
ffplay, a part of the ffmpeg package, is used in various operations to preview the music files. ffplay does not offer any graphical controls in its interface but you can control it with hotkeys. See the 3.6 While playing section of the ffplay documentation. The basic controls you may find handy are:
space bar : play/pause
left/right (arrows) : seek backwards/forwards 10 sec.