Two fine DAE scripts


Anybody that knows my command line habits, or me in general, knows that my memory could be better. It can be good when I need it to be, however, if I don’t have to remember a thing I’m writing it down. This is why I built my DAE scripts. DAE, which I pronounce as day, is an acronym for Digital Audio Extraction, also known as ripping audio CDs. The scripts are a wrapper for a command that has only a few options yet I have no way to remember the command options that I may not use again for awhile. Hence I created these basic scripts. They are straightforward scripts that just cover the essentials.

(These scripts are only basic wrappers, most of the work is done by the RipIt developer(s)… I thank them very much for their effort.)

How they look

There are two scripts. They are demonstrated here in use, as it is the best way to describe them.

daeme (pronounced like lame) is for MP3s:


daefe is for MP4s:


After these steps RipIt does a CDDB query from the Internet (if available) and allows tag editing if desired.


I bypassed adding a few settings in the script and rather allowed them to be specified in the RipIt configuration file as their values will likely remain the same:

dirtemplate="${artist} — ${album}"


The daefe script can also be used for audiobooks. The procedure encodes an entire CD to a file and writes a track/chapter index to another file. The chapter index file can be merged into the audiobook for an integrated audiobook, read ArchWiki:Audiobook for more details.


Both scripts have error checking and I consider them reliable. I have put them in a repository for anyone interested.

That audio I do!


When I looked at my audio files recently, I realized that that I wanted them organized in a consistent way. As it were naming standards varied, some tags were missing, different encoding types were used… I decided I was gonna Feng Shui my way out of it.

The reorganization department

I decided there should be consistent naming and it should be condensed as much as possible, yet still being understandable.

For the directory format I use $artist—$album. For many people the format is $artist/$album, however, I came to the term that I would have to have about 100 CDs in my collection before the list would get too cumbersome to navigate.

I decided also to do one directory per album. Before I had directory names like Fleetwood Mac — The Very Best of Fleetwood Mac (disc 1), but I discovered it was much tidier to use a base title: Fleetwood Mac — The Very Best of Fleetwood Mac then prepend the disc number to the audio files:

? ls Fleetwood Mac — The Very Best of Fleetwood Mac/
1-15 Songbird.m4a
1-16 Big Love (Live, 1997).m4a
1-17 Storms.m4a
2-01 The Chain.m4a
2-02 Don't Stop.m4a
2-03 What Makes You Think You're the One.m4a

There is another program that organizes multiple CDs in this fashion and I like the thought behind it.

Just the FAACs

I had been creating high-quality MP3s (256kbps) and just accidentally stumbled into trying MP4s—and was delighted by the difference. Similar bitrates of audio sounded fractionally, but for me, appreciatively better. So I encoded all CDs to .m4a (MPEG-4 audio extension). (I will probably go to loss-free audio format in the future if the gods favor.)

By the way, I think (clearly subjectively) that FAAC (Free Advanced Audio Coding encoder) is great. It mentions in the manual that “it is not up to par with the currently best AAC encoders” but from my semi-proficient audio setup it did well.

I tested encoding with a FAAC at a setting of 320 (~256kbps) versus the iTunes setting of 256kbps. I did find iTunes better. Audiophiles looking for every detail might talk but for me difference could be left alone.

Here is a partially non-scientific (but should be fairly representative) graph of FAAC’s quality settings compared to kilobytes per second:

I can verify for the first and fourth values as I have tested a number of times. The second and third values I got from hydrogen audio. The fifth value is a projected value based from the other values.

A FAAC setting of 150 has been recommended for “casual, non-critical listening”; however, I use FAAC 320 for my tunes and 55 for voice. Though similar bitrates to the iTunes encoder created slightly less quality, the file size reflected too: iTunes 8.4MB, FAAC 7.6MB.)

Softer player detritus

Software audio players that I have used tended to put a some extraneous files in my audio folders. I’ve seen album cover art put here, lyrics, some unnecessary metadata, and hidden folders. I did myself a favor and deleted them out. Nothing should be here but the audio files. If an audio player insists on putting stuff here, I would recommend to their users to file a bug so the developer can remedy it. Some may argue that album playlists should be put here but these I believe belong to saving along with the configuration files.

Book ’em, Danno!

I discovered a nice feature call the audiobook format. Instead of 100 tracks splayed over a directory, or directories, from a audiobook CD, I can reduce this to a reasonable amount (say, one file per disc or even less if I choose). These book formats can also contain chapter indexes so navigating a file is just like navigating a disc. The process isn’t incredibly difficult and I documented it here. If the audio player supports them, it is a nice feature.

Home directory organization


Being a Type A personality, I’ve probably thought more about this than many. I have a certain organizational style and formatting schema that I consistently think about.

Folder layouts

I keep all my home directories about the same as everyone:

# cd ~; ls -1p

One exception to the above is the “Audio” directory which I use for multiple audio types:

# tree -L 1 -d Audio/
├── Audiobooks
├── Music
├── Other
└── Podcasts

The other exceptions is I also hide the Templates directory (.Templates) as I don’t use it often.


Even though I use GNOME I’ve enabled the Desktop—this is my workspace. If I can see them, I can remember them.

# ls -1 Desktop/ | head -n 3


I’ve come to be a big fan of VCSs. If I build something that others can use on their computer, I’ll create a VCS for it. I’ve put all of these VCS directories in their own directory:

# tree -L 1 -F -i --dirsfirst Development/


I put all the Documents in one directory whether I wrote them or obtained them:

# ls -1p Documents/


I do the same with Pictures as I do my Documents; whether I designed, photographed, or obtained them, I put them here:

# ls -1p Pictures/ | head -n 7
aqua pr09studios.png

Naming conventions

For the major folders, I use single words with the first letter uppercase. For files and other folders, I try to keep to the somewhat-traditional Linux method of naming my files as lowercase. For spaces in files, I generally use a hyphen (-) which I see used a lot these days though I think an underscore was originally used. Underscores I will use if there is a category I would like separated in the name (portrait-of-bach_etching.svg).

Audio files

Read this post to learn how I organize my audio files.


When I come across a file that I won’t use anymore, is outdated, a misdirection, I create a folder called _vault and I place them in it. I then always have them around as I find that sometimes I like to.

Home directory regenesis

When some unexpected event occurs on my computer, I may begin by troubleshooting in the home directory. Lately, I was having several program loadings that were taking a good deal of time that explanation thereof was baffling—a resolution I was unfortunately not able to find an answer for. The realistic solution for me was to create a new user and copy the trusted files over to a new home folder. It turned out to be a fairly easy thing to do.

The quick and the darned

In the past methodically I would clean out my home directory. I did this every year or twice a year. I did this because usually a quirk developed here or there but also because I’m a type A personality. Why quirks occur can be of one of several reasons but it might be related to a program’s configuration files: like with the addition of a new feature to a program, or with an older setting interfering with a new feature, databases getting too large…

I have much respect for my configurations and I do my best to keep them. The methodology I have learned of how to interact with my programs I respect and try to keep around and develop. However, at times, configuration renewal may become necessary. I do this only when I have to.

All work and no play is OK

Business if more important when I come down to it. Going through all the files, is no doubt, a laborious process, however, the result is worth it when everything is again running correctly.

First, I create a new user:

# useradd --gid users --groups games,wheel --shell "/bin/bash" USERNAME 
# install --directory --owner=USERNAME --group=users --mode=700 /home/USERNAME
# passwd USERNAME

I then put all the directories and trusted configurations in a list:


Then transfer them using rsync:

rsync --archive --files-from=include.txt --exclude-from=exclude.txt /home/USERNAME-OLD/ /home/USERNAME-NEW/

Since both users are in the same initial group (users), I just need to change user ownership from the old own to the new and then I’m done:

find /home/USERNAME-NEW/ -user USERNAME-OLD -exec chown USERNAME-NEW {} \;

This process took me about an hour.

Vim colorscheme customization

Any installed Vim colorscheme has the ability to be customized. They can be tested temporarily or saved to a configuration file that will leave the original colorscheme file intact.


To customize a colorscheme value, Vim has on-the-fly colorscheme alteration support to be able to test them. To get an overview of what all the values look like:


To see a specific value (tip: have wildmenu enabled for tab-completion support):

:highlight CursorLine


To customized a value:

:highlight CursorLine ctermbg=255


  • hi = highlight
  • If working from the terminal, it is useful to know what colors are available. A number of scripts can be found; I created one called termcolors.
  • A test can highlight the current syntax groups: :so $VIMRUNTIME/syntax/hitest.vim

Save to file

Customized colorscheme values can be saved in the Vim configuration file or in the after directory with a plug-in.

It may be a good idea to begin customizing a colorscheme by reading the colorscheme author’s notes. Authors will sometimes explain their design philosophy in the colorscheme file. These files are located system-wide in /usr/share/vim/vimfiles/colors/ or locally in ~/.vim/colors.

Configuration file

A good number of users may prefer using the AfterColors plug-in as it simplifies the process and helps keep the configuration file neat. I prefer using the configuration file because of a glitch I encountered once.

Because it is possible that I may use multiple colorschemes, I’ve put detection of the colorscheme in my configuration so customizations apply per colorscheme. Values entered into the configuration match that done while testing:

if g:colors_name == "desert"
  highlight IncSearch  ctermfg=197 ctermbg=none
  highlight Search...

AfterColors plug-in

Vim uses the system directory $VIMRUNTIME/after/ and the local directory $HOME/after/ to supplement or overrule to the default settings. For editing colorschemes there will need to be a sub-directory called colors. To install it locally:

mkdir -p $HOME/.vim/after/colors

For neither, however, does Vim yet support colorscheme customizations and a plug-in will need to be installed: AfterColors. I would recommend using a plug-in manager like Vundle or Pathogen to install it.

Customization values are put in a file that matches the colorscheme’s file name:

touch ~/.vim/after/colors/desert.vim

The values placed in the files are the same as done while testing:

" Vim colorscheme customizations: desert
highlight IncSearch  ctermfg=197 ctermbg=none
highlight Search     ctermfg=126 ctermbg=none  
highlight CursorLine ctermbg=255
highlight Visual     ctermbg=45

Save the file and reload the colorscheme to see the edits:

:colorscheme desert

… or type colo for the abbreviated version.

gurl—a general downloader

I like to keep things basic. Because a command-line, download program is already a part of the base package installation, it is all I need. Once I learned curl I liked it quite a bit. As always I need help remembering the options so I wrote a general wrapper script and it seems to be all I need. It features redirect following, progress bar, and resume support. It looks like this:

# gurl http://.../archlinux-2014.09.03-dual.iso
###############################                                           43.4%

gurl can be found in my general scripts repository.

Some Vim colorschemes I came across

terminal with text editor

Most of the time when typing I’m pretty happy just doing that. But today I thought about it a bit and my colorscheme I realized I was hoping could do more. So today I updated my Vim colorscheme for the first time in two years. I came across some very nice ones. Here are a few of them. (Click image to visit their websites.)






This is the colorscheme I decided on for when I like a dark background, and I customized it a bit:

" Vim colorscheme customizations: jellybeans

highlight Normal     ctermbg=323232
highlight Normal     ctermbg=303030
highlight CursorLine ctermbg=238
highlight Visual     ctermbg=240



This colorscheme is what I’m going to use for awhile. Because I spend a lot of daytime at the terminal, this colorscheme works well for the eyes. I like it quite a bit.


I also made a few edits for this one:

" Vim colorscheme customizations: pencil

set background=light  " override dark as colorscheme forces

highlight CursorColumn ctermbg=255
highlight CursorLine   ctermbg=255
highlight Normal ctermbg=none
highlight IncSearch    ctermfg=197 ctermbg=none
highlight Search       ctermfg=199 ctermbg=none

Thank you to all the colorscheme designers who have helped my editing out.