Saturday, 7. November 2009
I recently had several tracks stop playing in iTunes and they all had one thing in common, a duration of 789:57:13. The recommended solution for this problem is to re-rip or re-download the track. That wasn’t an option for some of these tracks because I purchased them through iTunes and the official Apple stance is that you are only allowed to download a purchased track once and I didn’t want to re-purchase the tracks. Restoring from backup also wasn’t an option for some of the tracks because they were munged in even my oldest backups.
The solution I found was faad and faac – Freeware Advanced Audio Decoder/Coder. It will decode unencrypted AAC/MP4 files and will happily ignore and correct the munged frame duration in the MP4 wrapper. I recovered a damaged track like this:
faad "09 This Devil's Workday.m4a" -o "09 This Devil's Workday.wav"
mv "09 This Devil's Workday.m4a" "09 This Devil's Workday.m4a.bad"
faac -w --artist "Modest Mouse" --title "This Devil's Workday" --album "Good News for People Who Love Bad News" --track 9 --disc 1 --year 2004 "09 This Devil's Workday.wav"
As faad was decoding the original track it showed that the MP4 wrapper’s duration was, but it corrected as it decoded it.
MP4 seems to have incorrect frame duration, using values from AAC data.
Decoding 09 This Devil's Workday.m4a took: 1.62 sec. 85.94x real-time.
When faad/faac were done I was able to re-import the track into iTunes and play it successfully.
I lost some of the iTunes metadata from the original track, mainly the cover art. iTunes automatically added the cover art when I re-imported it, but that only works for music in the iTunes library. In those cases, faac has an option to import cover art from an external image file. You can do the same thing with iTunes as well.
If you have a lot of tracks to repair, adding the metadata manually on the command line is tedious. However, it could be automated with a simple script that captures and processes the output of faad since it displays all the track metadata as it is processing.
Cross-posted on deanfranklin.net.
Saturday, 3. January 2009
I use ssh all the time, but I rarely use it to connect to my MacBook. Today my MacBook froze hard and I tried to ssh to it from my Linux box in an attempt to recover. The ssh failed with the following error message:
dean@xbrain:~$ ssh 192.168.1.200
Received disconnect from 192.168.1.200: 2: Too many authentication failures for dean
My first thought was that DenyHosts had borked me but that turned out not to be the case. (If you aren't running DenyHosts you should be.) I tried ssh with debug messages turned on and the client was offering the correct public key but the server was rejecting it. I ended up just doing a hard reboot of the MacBook but I still wanted to solve the prolem.
Next I assumed that something in my private or public ssh keys was borked. Searching on the error message I was getting led me to believe that I had file permission problems somewhere but my
.ssh directory had all the correct permissions – 0700 for the directory and 0600 for all the files inside. I edited
sshd_config with the intention of enabling PAM and password authentication. Instead the following two lines caught my eye:
First I changed the value of
MaxAuthTries to 3. I was rewarded with a new error message from the ssh client.
dean@xbrain:~$ ssh 192.168.1.200
Permission denied (publickey).
After that when I turned on debug messages for the ssh client I could see that after the initial public key authentication failed it tried to find other allowed authentication methods and when it failed gave me the error above. Next I changed the value of
no. After making that change I could successfully ssh. This confirmed that there was a file permission problem on the server side.
Specifies whether sshd(8) should check file modes and
ownership of the user's files and home directory before
accepting login. This is normally desirable because
novices sometimes accidentally leave their directory or
files world-writable. The default is "yes".
I had always assumed that
StrictModes only applies to the user's
.ssh directory. It turns out that it also checks the file permissions on the user's home directory and will balk if the home directory is writable by group or other (everyone). My home directory was writable by group and this was the root cause of the errors I had been getting. (The default user group is
staff on OS X but it varies on different operating systems and distributions.) After removing group write permissions from my home directory and restoring my original
sshd_config settings everything started working the way it was supposed to. From a review of my Time Machine backups it looks like some time in December I accidentally (or perhaps even intentionally) changed my home directory to a drop box which turned on group write permissions. Doh!
Monday, 7. April 2008
I should have looked before I wrote my last post on MySQL because there is an updated version of the MySQL package for OS X 10.5. (And it has been available for quite a while too.) I undid everything I had done previously to get MySQL working before and I downloaded and installed the 64-bit version of this new package. I even took myself out of the
After installing the updated package I found that I could not start MySQL from the command line or the prefpane. I tried adding myself back to the
wheel group but I still couldn't start MySQL. To fix the problem I still had to follow the recommendation to change the ownership of
/usr/local/mysql/data that I originally found here. Then I removed myself from the
wheel group and I could still start and stop MySQL from both the command line and the prefpane. I'm not sure that changing the permissions is either really necessary or the best solution to the problem but it works.
Then I tried restarting the system to see if the permissions on
/usr/local/mysql/data/<computer name>.local.err were getting reset like they were before. They weren't, so that's one less problem to deal with.
Finally I tried enabling automatically starting MySQL on system start and that works now even if your user is not in the
So now (almost) everything in the MySQL package for OS X 10.5 works out of the box.
Monday, 7. April 2008
In an earlier post I explored how to install MySQL from a package on OS X Leopard, but I left unsolved the problem of how to make MySQL start automatically on system startup. This morning while reading Mac OS X Hints a post titled “10.5: Join 'wheel' group as possible fix for system issues” caught my eye and started me thinking that perhaps it might also be a solution for the MySQL auto-start problem I had been unable to solve.
First I had to find a way to add myself to the
wheel group so followed a link from that hint to another hint titled “10.5: Manage users and groups using a GUI tool“*. From there I downloaded and installed Apple's Server Admin Tools for 10.5. These tools are not meant to be used with the desktop version of OS X, but the Workgroup Manager tool works and can be used add a user to a group. I followed the steps described and added myself to the
wheel group. It took me a couple of minutes to find the
wheel group because the Workgroup Manager displays the groups' long names instead of their short names. In the case of the
wheel group the long name is
After adding myself to the
wheel group I opened the MySQL prefpane in System Preferences and checked “Automatically Start MySQL Server on Startup”. Then I shut down and restarted my MacBook. When it finished booting I logged in and MySQL was already running. Problem solved!
*Mac OS X Hints offers the following warning for this hint:
Warning: You should not play around with these settings if you don't know what you're doing. It is possible to break certain parts of the operating system, or to render it unusable.
You should definitely not add users to the
wheel group unless you are reasonably confident that you know what you are doing and what the security implications are.
Thursday, 14. February 2008
Apple made a minor but welcome improvement to Stacks with the 10.5.2 upgrade. You can now change the stack icon on the toolbar to a folder icon. So now instead of seeing this:
I see this:
I am much happier seeing the Application folder as my Application stack icon than I was seeing the 1Password icon. To change your Stacks icon display, right-click on the stack you want to change and select Display as: Folder. If you don't like it then change it back to Display as: Stack to see 1Password, Address Book, Adium or whatever icon is first in your Applications folder.
Thursday, 14. February 2008
Tuesday, 5. February 2008
There are two options for installing MySQL on OS X, assuming you aren't running OS X Server which includes MySQL. The first option is to install it from source. The second option is to install it from a package. I've installed MySQL from source before and it is not a terribly difficult process, but for some unknown reason (perhaps related to my incorrigible tendencies towards sloth) I had a strong preference for installing it from the package.
The problem was that the current MySQL package isn't exactly compatible with OS X Leopard. I found a solution to that problem in this post on The Blog that Noone Reads. As suggested there, changing the owner of all of the files and folders found in
/usr/local/mysql/data fixed the problems I had with MySQL after installing it from the package. Almost. Every time I rebooted MySQL would refuse to start from the prefpane. It turned out that there was a log file whose ownership was getting reset every time I restarted. The fix for that was to leave the ownership on that file alone and to change its permissions instead. Remember to change
<computer name> to the computer name of your Mac before running the following command:
sudo chmod a+rw /usr/local/mysql/data/<computer name>.local.err
After changing the permissions of that log file I am able to start and stop MySQL from the prefpane even after rebooting.
There is still one problem left to solve – I cannot get MySQL to automatically start. But as usual I decided to declare victory at the 90% success mark and leave a bit of the problem unsolved to satisfy the procrastinator in me. Besides, I didn't want MySQL to start automatically anyway.