Using Linux to manage a large audio collection
Music recording technology has gone through an amazing number of technology changes in the last 30 years. First there were reel-to-reel tapes, then audio cassettes. VHS-HiFi was a short-lived medium that offered improvements over cassettes until the audio DAT tape showed up. After that was CD-R media. Add to that vinyl records, commercial CDs, sound tracks from video tapes, and live recordings from multi-track digital recorders. Recently, a large number of BitTorrent sites have been good sources of live music recordings.
Your author is somewhat picky about audio standards, although he routinely shuns audiophile audio hardware. The Microsoft .wav file format seemed like the universal standard to use as an archive medium. The 44.1K sampling rate was chosen due to its compatibility with audio CDs. Compressed formats like Ogg Vorbis and MP3 have their uses for portable players, but for archiving purposes, .wav is for the most part, the best sounding and most universally workable standard.
Taking that one step further, .wav files can be bit-for-bit converted to and from FLAC, the Free Lossless Audio Codec. FLAC typically squashes music by about 50% of its original size, and .flac files can be played directly with music players such as XMMS. It is trivial to re-convert .flac files to .wav for burning CD-Rs.
The standard Linux filesystem was chosen as way of storing the archive. It offers a wealth of handy command-line utilities for management, and GUI-based interfaces for those who prefer the that mode of operation. Some conventions were chosen for representing the music from a typical live concert. Each concert gets stored in a unique directory named ArtistYYYYMMDD. Individual songs were stored in their own .wav files with a similar naming scheme: ArtistYYYYMMDDd#T##.wav where YYYYMMDD is the date, d# is the (optional) disk number from a multi-CD set and T## is the track number. Additionally, a file called ArtistYYYYMMDD.txt can be included to contain a textual description of the audio source, processing information, song lists, and other information. It would be nice to have a meta-data file such as an XML file that contains more information in a computer readable format, but that's for the future.
A big collection of CD-burning source material was recently rescued from an old computer system and a big pile of backup tapes from the same machine. The majority of this data consisted of 1-2 GB .wav files that were created by copying audio DATs into a CMI8732-based sound card with a lossless S/PDIF digital audio interface. The audio stream was converted to .wav files with the obsolete SoundRecorder utility, or Cinelerra. Sound from analog sources was fed into the computer using an external Flying Cow Analog to S/PDIF converter.
Many of the audio DATs were recorded with a 48Khz audio sampling rate; those were converted to 44.1Khz files with SoX. Most of the source material was stereo volume normalized with Ecasound and some custom audio scripts. Volume normalization is a bit of an art, it usually works best on large parts of the source .wav file, broken up by concert sets, or where the person running the recorder tweaked the recording level. Normalizing groups of songs gets rid of annoying volume changes from song to song.
Although Cinelerra is primarily a video editor, it has the critical ability of being able to digest a 2GB audio file without choking. It also has the ability to mark audio edit points throughout the source material, and bulk-render individual .wav files as marked by the edit points.
After all of that, the music archive is showing many signs of improvement. All of the long gaps and audience chatter has been removed from the source material. The volume of the .wav files is fairly constant from concert to concert. The songs are now accessible individually. Your author was lucky in that he discovered how poor the CD-R medium is for long time archiving before he deleted his source .wav files. CD-R media degrades with heat, dirt, and repeated handling.
Now that the music archive is coming together, some big advantages are beginning to surface. It is possible to copy the entire archive to another computer with a one line ssh/tar command. This is extremely powerful for backing up the data or copying sections to a friend's computer. A spare computer can easily be retrofitted with a large hard drive, then turned into a music library audio appliance. Although not as portable as an mp3 player, the entire archive can be copied to a laptop for listening away from home.
This is very much a work in progress, it is also a process that will never be finished. The archive is up to 45Gb and is growing daily. Some software remains to be written. A random music player should be easy to write with just a few lines of Python code. That could be extended to include more advanced features such as noting song groups that should always be played together, and skipping files that contain short spoken segments such as a band introduction. In the source material, files are occasionally split into two pieces due to the editing out of a bad section in the middle, your author is still searching for a way to join two .wav files into one to fix that problem.
Linux and the wide variety of open-source
tools have made this entire process a breeze, if somewhat time
consuming. Audio recording has gone through a series of diverging
technologies, this distillation effort has reversed that trend.
Posted Mar 9, 2006 4:55 UTC (Thu)
by botsie (guest, #1485)
[Link] (1 responses)
Posted Mar 9, 2006 18:07 UTC (Thu)
by cook (subscriber, #4)
[Link]
Posted Mar 9, 2006 5:15 UTC (Thu)
by jwb (guest, #15467)
[Link] (2 responses)
Posted Mar 9, 2006 9:56 UTC (Thu)
by dion (guest, #2764)
[Link]
If I had a bunch of music sampled at 48k then I'd do everything I could to preserve it like that.
... oh and why not use flac in stead of wav?
Posted Mar 9, 2006 18:03 UTC (Thu)
by cook (subscriber, #4)
[Link]
Posted Mar 9, 2006 6:01 UTC (Thu)
by felixfix (subscriber, #242)
[Link] (1 responses)
Meanwhile I have lots of plans ... it is a command line program, works nicely as a daemon, talks over a socket to control programs. I have lots of ideas for a GUI interface over the socket, for ripping, playing, burning ... exporting it with an SQLite dump of the database ... but no time and flaky sound sure don't make for progress. It seems like altho gentoo trends better over time, individual releases periodically break USB and/or audio, so it is a major frustration working on it.
I hope your project has better success.
Posted Mar 9, 2006 18:35 UTC (Thu)
by lysse (guest, #3190)
[Link]
I did such a thing myself recently, although on a smaller scale - but instead of using SQL, what I did was simply: So my everyday music player has simply become: and if I want visualisation, I can start up synaesthesia. Hardly the most exotic of players, but it does what I want. If I wanted to ensure that certain tracks fell in runs, I could do that by adding a layer of indirection - numbering playlists and having mpg321 play them back instead. At some point I'll add a timestamped log and some basic transport control, when I get sufficiently annoyed to do so. I might even add all the ID3s back in...
As you might have gathered, I don't go much for GUIs (am I the only person who never worked out what the point of a file manager was?), and I am a great advocate of doing the simplest thing that can possibly work now :)
Posted Mar 9, 2006 10:23 UTC (Thu)
by seyman (subscriber, #1172)
[Link] (5 responses)
your author is still searching for a way to join two .wav files into one to fix that problem. Forgive me if I'm wrong but shouldn't this be as simple as "
Posted Mar 9, 2006 10:49 UTC (Thu)
by HenrikH (subscriber, #31152)
[Link] (2 responses)
Posted Mar 9, 2006 18:41 UTC (Thu)
by lysse (guest, #3190)
[Link] (1 responses)
Posted Dec 6, 2006 20:28 UTC (Wed)
by cook (subscriber, #4)
[Link]
Posted Mar 9, 2006 10:51 UTC (Thu)
by k8to (guest, #15413)
[Link]
Wav files have headers which such things as content type (not necessarily PCM!) bitrate, stereo/mono, and probably length, although I am not certain of this.
If the two wav files were of the same type in every way, and if the RIFF headers that are what makes a wav a wav do not actually indicate content length, you would still get an unpleasant burst of noise in the datastream when transitioning from the first body of data to the second. Additionally, I do not believe there is any mechanism which would guarantee correct byte alignment of the high and low order bytes of the left and right channels.
Posted Mar 9, 2006 11:00 UTC (Thu)
by arvidma (guest, #6353)
[Link]
Posted Mar 9, 2006 22:39 UTC (Thu)
by climent (guest, #7232)
[Link]
abcde has recently included a new way of ripping CDs: 1 single FLAC file with embedded CUE sheet.
It can be used as a source to obtain the original tracks contained in the CD. Also, the CUE file can be saved separately as .cue file, which is understood by some programs like xmms to play just a single track from within the FLAC file.
Hope someone finds this feature useful, and sends patches/bugs with improvements/problems.
Posted Mar 10, 2006 1:55 UTC (Fri)
by ramme (guest, #4522)
[Link] (1 responses)
Posted Mar 10, 2006 7:45 UTC (Fri)
by man_ls (guest, #15091)
[Link]
Worst publicity ever.
Posted Mar 14, 2006 2:50 UTC (Tue)
by omez (guest, #6904)
[Link]
Posted Mar 17, 2006 6:00 UTC (Fri)
by RMetz (guest, #27939)
[Link] (1 responses)
I've needed to get to work on a project like this for a REALLY long time, this article is going to be a great help. It is also the single funnest article I've ever read on LWN, makes me want to stop working and delve into my collection right now - I just got a show that no one I have spoken with except the guy I got it from believes that a recording exists.</deadhead>
Thanks!
Posted Mar 17, 2006 6:03 UTC (Fri)
by RMetz (guest, #27939)
[Link]
Thought I'd try.
Hmmm ... now our esteemed editor can claim to be *working* when he's sitting around ripping CDs. Jeez, I wish I could tell my boss the same thing.Using Linux to manage a large audio collection
>now our esteemed editor can claim to be *working* when he's sitting around ripping CDs.Using Linux to manage a large audio collection
Hey, this is *bleeding edge* research ;-) besides, the boss wants
a copy of the dataset.
Why did you convert the DATs to 44.1KHz? I ask because, in the first place, sox uses an incredibly bad sample rate conversion algorithm with high distortion. Secondly, because most computers can record and playback at 48KHz just fine. In fact many computers can only playback at that sample rate. And finally, 48KHz operation is almost universally supported in the external DACs to which you might hope to connect your computer's S/PDIF port.Using Linux to manage a large audio collection
My thoughts exactly, it may not matter much because it's only the higher frequencies that get trampled, but converting from 48k to 44.1k is going to cause the same kinds of problems as when you run 800x600 on a 1024x768 lcd screen.I'd like to second that.
> Why did you convert the DATs to 44.1KHz? Using Linux to manage a large audio collection
A legitimate question, I don't like resampling because it
loses information. It's mostly a historical decision, the files were
resampled several years ago when my goal was to burn everything onto
CD-R. I already have a large dataset that is all at 44.1K.
My recent effort has been trying to rescue all of that processed CD
source data. Besides, I still may want to burn the occasional CD-R and
it simplifies that process to start with 44.1K files.
I have not really noticed a big change in sound quality, but my ears'
high frequency response isn't what it used to be.
On a similar topic, I played with a SoundBlaster live card a while back,
feeding 44.1K data to its S/PDIF input causes it to convert to and from
its 48K internal clock frequency, leaving noticeable audio distortion.
I prefer inputting S/PDIF through the CMI8738 chip, it is basically a
simple UART. One *does* have to uncomment some lines in the kernel
driver code to make S/PDIF input work on the 8738.
A couple or three years ago, I started a similar project, but I wanted to use SQL to manage things, so I could tag all music with dates, keywords, etc, and select, say, all Elvis Christmas songs recorded before 1960. I do not like playlists; I want to make my choices on the fly. I have about 2/3 of my 2000 CDs on hard drives, with two backup copies, stored as flac files, and the project works well enough to be minimally useable, but then my computer died (too many disk drives without checking for power supply overload), and I foolishly decided to try a dual opteron system. I have had nothing but headaches over the USB and audio, and whether that is due to SMP, or 64 bit, or gentoo, I don't know. Plus a new job, and I ran out of time ... a friend talked me into putting it on source forge, which I regret, as it is not really ready for prime time. It does work after a fashion, but it needs too much TLC for anyone else, and I hope no one actually tries to use it; that would be too embarassing for words :-)I started such a project too :-)
Me too...
tNNNN :: artist--track-name--version--remixer
while true; do
while [ "$N" == "$T" ]; do
N=`printf 't%05d' $(( $RANDOM % $TRACK_COUNT ))`
done
grep $N /music/directory.txt | sed -e 's/^.* :://'
mpg321 -o esd -q /music/$N.mp3
T=$N
done
Using Linux to manage a large audio collection
cat file1.wav file2.wav > total-file.wav
"?
If I am not mistaken there is a header in the wav files so you cannot simply cat them together.Using Linux to manage a large audio collection
You can simply sox them together, though: sox first.wav second.wav both.wav ought to do the trick. (NB. not tried!)Using Linux to manage a large audio collection
>You can simply sox them together, though: sox first.wav second.wav both.wav >ought to do the trick. (NB. not tried!)Using Linux to manage a large audio collection
This works with newer versions of sox, thanks for the tip.
It is not this simple.Using Linux to manage a large audio collection
Open them both in audicity. Copy, paste, save. Might want to use a quick fade in/out or add some silence in between. A 30 second job.Using Linux to manage a large audio collection
(Time to pride my own tool)Using Linux to manage a large audio collection
Contact me for a copy of songbase. Songbase is music managing software that enables you to store all of your CD's on hard disc, capture hit lists, maintain playlists, artists, records and songs. Everything is hyperlinked of course. Built-in features are an audio player and CD ripping (CDDB connection required).Using Linux to manage a large audio collection
Contact you? Don't you have a website, a URL or something? I couldn't even Google it, unless it is software for "worship leaders" whatever that is. Is it a legal copy that you provide? Is it free software? I expect it's in source code form at least? What are the requisites?
What is this songbase?
Using flac's --replay-gain option will annotate the header leaving the source data untouched. The calculated gain factor can then be extracted from the header and applied during playback.Normalization
You're a tape trader? I'm a trader!HEY NOW!!
I wonder how many of us there are amongst the LWN readership. Anybody for a LUG Tape Trader Network? Anybody?HEY NOW!!