Tag Archives: linux

Punch and Roll for Audacity in Linux using Autokey

audacity_logoMost of my friends know that as a side-line I narrate books for Audible.Com, and they might also know that I’m a Linux nerd, too.  Where those interests intersect, there is a wonderful open-source program called Audacity, which is a Digital Audio Workshop, that is, a program in which you can record, edit and master digital audio.  Musicians, narrators and voice-over professionals use such programs every day. Audacity, in addition to being jammed with features and options, is free. It’s the very tool to reach for if you are a dabbler, or on a constrained budget, but serious about doing good work.
Unfortunately, Audacity  lacks one capability which narration and voice-over, in particular, makes heavy use of, and that is a tool called “punch and roll”.  “Punch and Roll” allows an audio book narrator to edit mistakes “on the fly” while reading. It works like this: the reader hears himself flub a line or a pronunciation, stops recording, places the start-point line just upstream from the mistake, and hits “punch and roll”. Then these things happen automatically: the start-point jumps upstream an additional pre-set number of seconds (2-3 seconds are typical), the system starts playing the audio for the narrator to hear. As the time-line reaches the marked “flub-point”, the system stops playing, and begins to record. The narrator picks up reading, correcting the error, and the recording proceeds, as before, with the edited audio right where it belongs.

Ideally, the program should preserve both the original audio (the one containing the error), as well as the corrected stream. That may sound odd, I know, but is no less true. It doesn’t happen often, but it can be very important at times to have the original stream of audio, to fix subtle issues found much later on.  Being able to revert to the original version with the tool is called “non-destructive punch and roll”.

So, how can we do all this in Audacity? First know this: the Audacity DAW has versions that run in Windows and Mac, as well as Linux, and there have been a few clever people who have solved this problem for those systems already. My “punch and roll” solution for Audacity in Linux has been adapted from a solution posted by Steven Jay Cohen which works in Mac OSX. Cohen’s written a short piece of code that runs in AppleScript, to execute the correct keystrokes to allow non-destructive punch & roll in Audacity on a Mac. A bit of googling will also locate scripts that will achieve similar results using “AutoHotKey” on Windows computers.  My solution for linux makes use of a powerful macro utility called “autokey”, which runs scripts in the python programming language.

Here’s how to obtain punch and roll in Audacity on an Ubuntu/Debian linux computer:

1. Install autokey. On a gnome-ubuntu machine, from the command line run:

sudo apt-get install autokey-gtk

2.  From the desktop, launch the program menu, then Accessories, AutoKey. This should open the Main Window of autokey, and also place the autokey icon, a capital “A”, in your program tray.

The main window looks like this:

AutoKey Main Window
AutoKey Main Window

Now you are going to add a new script to the existing library you see on the left side of the main window. Do these:

1. Click where you see “+New”, choose Script from the menu, then give your script an appropriate name in the dialogue box. I called mine Punch&Roll.

2. Notice on the right side the box where you will input and edit your script. It’s marked # Enter script code:

#Enter Script Code
#Enter Script Code

blogYou will be pasting the code right below where you see:

# Enter script code

For those of you unused to working with programs, understand that where you see a hashtag (#) at the beginning of a line, the computer ignores that line when running the program. If you are modifying this script to troubleshoot it, you could insert a hashtag at the start of a line to remove it temporarilly from the program, or to create a note for yourself about what the next line is supposed to do.

Here’s the script that works for me. It sets 3 seconds of pre-roll:

##‭ ‬Autokey script to enable Non-Destructive Punch&Roll
‬##in Audacity using AutoKey.
#The number of “,” below sets 3 seconds of pre-roll.
#Below, (” “) encloses one press of the space-bar.
keyboard.send_keys‭(” “)
#Number for time.sleep below should equal number of (“,”).
#Delay for sleep below makes resume-record work.

After copying this into the script editing box in autokey, do three more steps:

1. Set a hot key for the script, by clicking on the button below the script marked HotKey….Set. Then in the dialogue box that opens, click on “Press to Set”.  Choose a hot-key combination that doesn’t conflict with any other program or function: I recommend a combination of the <super> key (also called  the <windows> key) and the “z” key. So press and hold <super> and then press “z”. Then press Ok. You should see <super>+z has been set as your hot key.

2. It’s wise to set a Window Filter, so that your hot key will only be activated within Audacity. Where it says Window Filter, press Set. In the dialogue box where it says “Regular expression to match”, type in   Audacity.Audacity   ,  just like that.

3. Lastly, save your work: Click up above where it says Save, or simply press Ctrl-s.

Now, to use “punch and roll”, you need to set up Audacity very specifically for the script. It expects you will have two mono tracks above a label (bookmark) track. Audacity will launch a new track as soon as you begin recording, so I do these steps to get started:

1. Make sure AutoKey is running in the background (the “A” shows in the tray below on the right side).  Now launch Audacity, and make a short recording of 5-8 seconds.

2. Press “Ctrl-Shift-n” to make a second mono track below the first.

3. Press “Ctrl-b” to make the label track.

The top-most track is your production track. The next one down is your Edits track and will accumulate your saved mistakes as you stop, set, and then punch/roll to fix “flubs” on the fly.  It should look something like this:

Set up these tracks: Production, Edits, Bookmarks
Set up these tracks: Production, Edits, Bookmarks

To try it, you need to start with the time-marker set within the short piece of audio you recorded to launch the production track.

1. Put it near the end, but not all the way at the end.

2. Press <super>+z, and you will see the time marker jump back 3 seconds, play those three seconds, and then append a new recording to the production track as it reaches where you started.

You will also notice that all audio AFTER your start point will have been moved to the second audio track, where it will be saved, in case it’s needed to fix something. Here’s what it should resemble:

After one "punch & roll". Notice that my Edits track is muted, so it doesn't distract me as I re-record.
After one “punch and roll”. Notice that my Edits track is muted, so it doesn’t distract me as I re-record.

So there you have it! Non-destructive punch and roll for Audacity in Linux. My deep appreciation to Steven Jay Cohen for his excellent post explaining this process for Macs, without which this technique would still be a mystery to me.


HTC Incredible and Jelly Bean: How I almost “bricked” my phone, and what it took to recover it:

I feel I owe it to others who may have done likewise to set out a record of what I did, and how I fixed it. The notes that follow are VERY technical and arcane to the world of hacking one’s smartphone, and for most of my blog’s readership I’d suggest passing this one by, unless you are hip to this kind of stuff. If you want to read on from curiosity, well, good for you!


What this is NOT: This isn’t notes on how to successfully get Jelly Bean on your Dinc. It’s all about recovering from a phone that is trapped in a boot loop after attempting to get Jelly Bean, and is further incapable of loading and booting a nandroid recovery rom.adr6300


My phone is a Verizon ADR6300, ie, an original HTC Incredible, and pretty old as smartphones go. As soon as I obtained it, I rooted the device, and have from time to time done my own Android upgrades by cook-booking the process from information in the various forums.


It was running Cyanogenmod 7 and somebody’s stock rom of Gingerbread since last summer, and as I’d had good success a few days earlier updating my Toshiba Thrive tablet to Jelly Bean, I was looking to see if this was now possible for the “Dink”.


Notes on the phone, how it was rooted, etc, because I’m fairly certain that being non-specific about those details is what may have led to my problems:



Android v.2.3.7


Kernel @folkvanger #6

CPU ARMv7 Processor rev2 (v7l)

Mod version: CyanogenMod-7.2.0-inc

Build: GWK74


The phone had been rooted using the techniques shown at unrevoked.com , but quite some time ago: more than two years, I think, and without any recent updates. THIS IS LIKELY WHY I RAN INTO TROUBLE.


Here’s the specifics on how my Dinc was set up as unrooted at the time of my near-bricking, using unrevoked-forever, with PB31IMG.zip, and S-OFF. The bootloader showed this:








ClockworkMod Recovery v2.5.0.5



Setting out:


I read up on how to update the Dinc to Jelly Bean, made a nandroid backup of my current working installation, backed up my contacts, used TitaniumBackup for my apps, and downloaded a Jelly Bean rom, and the associated Gapps.


I booted the phone into ClockworkMod (volume down + on to HBOOT, then select RECOVERY with vol up/down, then press ON). Once in the Clockwork menus, I used vol up/down to select wipe data/factory reset, committed to it, and executed it. Next, selected wipe cache partition, committed to it, and executed it. Next, went to the advanced menu, selected Wipe Dalvik Cache, committed to it, and executed it. Those three tasks done, navigated to the main ClockworkMod menu again (one press of on/off button), scrolled down to ‘Install Zip from sdcard’, and selected the CM-10 rom for installation. I used this one from http://goo.im/devs/tiny4579/inc/cm10 , cm-10-20130118-TINY-inc.zip . After that installation ran, I again chose ‘install zip from sdcard’, selected gapps-jb-20121011-signed.zip , and installed that.


Unfortunately, I didn’t closely note the messages generated by those two installs. Anyway, as I went to reboot the phone, it got as far as the white HTC Incredible screen, and got no further. It was hung up at that screen for longer than 30 minutes, and could not progress. In the next couple of hours, I tried a different Jelly Bean rom, with no better results. (the rom was this one: jellybean-inc-RC3.zip) .


At that point, I abandoned trying to make JB work.


Fortunately, I was still able to get into HBOOT and CWM, so I selected ‘backup and restore’ in CWM’s main menu, selected ‘restore’, pointed it at my nandroid backup of Gingerbread that I’d made that morning, and launched it. Alas, it reported a number of errors, and was unable to build a working android system in the phone. It got past the white HTC Incredible start up panel, but went dark beyond that, and wouldn’t boot. The best clue was an error resembling this one:


E: Can't mount /dev/block/mmcblk0p2 (File exists)

The next eight hours or so were spent in searching for a fix online. The most helpful post I found was this one: http://forum.cyanogenmod.org/topic/6433-solved-messed-up-partitions-on-internal-storage/


The thread concerned a guy who was getting pretty much the same errors I was experiencing on attempting the nandroid recovery. There were two partitions in the phone’s memory that were failing to mount. His errors (below) were almost identical to mine:


E: Can't mount /dev/block/mmcblk0p2 (File exists)
E: Can't mount CACHE:recovery/log
E: Can't mount /dev/block/mmcblk0p2 (File exists)


Alas, I didn’t precisely record my error messages at the time, but they were VERY close to his, and centered on being unable to mount the /data and /cache partitions of the phone’s memory. The thread with these clues was very long, but the key help came from this section (#7) Here’s what he wrote:




Here’s the solution.

The problem was that I managed to screw up the partitions on my internal storage card, so basically nothing would work properly.  I could still get into recovery, though.  That’s key.

Here’s what you’ll need:

  • Working recovery, basic knowledge of adb & the shell
  • Parted (download here)
  • stock PB31IMG.zip

Note also that I had run unrevoked forever (so my phone was S-OFF) … I’m not sure if that’s required or not.

So, grab parted from the link above.  Now you need to extract the individual binaries from the .zip (the 6 files in the sdparted folder within the zip), ideally to your android-sdk\tools directory.  Now push all 6 files (adb push [file] /sbin/).  Next, we need to make them useable, so go into the shell (adb shell).  Change to your /sbin/ directory, and run: chmod 0755 <file> on each of the 6 files.

Now, we need to fix the partitions.  This is assuming that the partitions are there, just the wrong format (which is what happened to me .. I accidentally made them FAT32 instead of ext).  So, run the following: parted /dev/block/mmcblk0 mkfs ext2.  It will ask if you want to continue, hit yes.  When it asks for the partition number, enter 1.  Next, when it asks for the format, enter ext2.  Let it do its thing.  Now, once it’s done, run parted again.  This time, enter partition 2 (everything else is the same).

Once all that’s done, your recovery program should be able to mount both the /data and /cache partitions.  If that’s true, you’re pretty much done!  One thing I found was that I couldn’t directly install a new OS (I tried both Cyanogen and Ultimate).  In both cases, it would look for stuff in the davik-cache that it couldn’t find, so something wasn’t installing correctly I think.  So, if that happens, flash back to the stock PB31IMG.zip (put it in the root of your /sdcard/ and let hboot install it), and then root your phone anew.  That’s what I ended up doing.


Now, there WERE differences between his situation and mine. Most of his problem seemed focused on the partitions having been somehow reset to the wrong filetypes. On my phone, the filetypes appeared to be ok, but I suspect that they had been resized somehow by the Jelly Bean installer rom. Nevertheless, the basic steps this guy had taken to recover his phone ARE WHAT WORKED for me.

If you’ve read this far, I’m guessing you have an almost dead Dinc, and are hoping for a precise guide of what to do next. Be warned! I’m only reconstructing the late hours of a very bad day from memory, so please take the following notes as an outline to guide you, but IT’S NOT A RECIPE you can completely trust. You’re going to need to read, and think, and proceed cautiously if this is going to work, maybe. If you don’t have command-line experience in linux, and a basic understanding of navigating through file structures and permissions, and using command line partitioning tools, well, go find someone who does, and ride shotgun as they try this out for you.

Here’s what I went and did:

  1. I installed android sdk tools to my Windows desktop system. Google was helpful in locating a download for them: http://developer.android.com/tools/sdk/tools-notes.html
  2. The main thing about step 1. is getting ADB working as a command you can access from the Windows Command box. I’d used ADB before, and there was a re-learning curve to get the hang of it again, but this guide was helpful getting started: http://droidlessons.com/how-to-install-adb-on-a-windows-7-pc/ The business about changing the path variable isn’t really necessary, because you can execute adb if you simply navigate to where you installed it. It’s less elegant, but I was in a hurry to fix my damned phone.
  3. Follow the guy’s link (http://www.sendspace.com/file/w6hi6x), and download the sdparted-recovery.zip file. It’s a command set of partitioning tools. Unzip and put those executable files into the same place where adb.exe is, so it’s easy to move and use them where needed when you get to that part.Ok, those first three steps all took place on your desktop system. It’s time to connect your phone to the desktop and test adb’s ability to work within the phone.:
  4. Connect the phone’s usb cable to the desktop system, and boot the phone with “vol down + on” to get to the HBOOT screen. Watch the messages there. After a few seconds you should see HBOOT USB PLUG. Then launch Recovery from the HBOOT menu. The phone is now tethered to the desktop.
  5. Test adb, by running cmd to open a command line box on the desktop. (Win+R keys together, then type cmd in the Run Window). Then navigate using the cd command to the path where you installed sdk tools, and the parted tools. (For me the path I used was c:\program files\android\android-sdk\platform-tools). The dir command will show you if adb.exe is in there. If so, try typing:

 adb devices 

 If the desktop is connected to your phone, it will give you;

List of devices attached

HT00XX1234 …… recovery

…or something like that.

If you’ve unzipped the six sdparted files into the same directory as adb.exe, then you are ready to move those files into your phone using the command:

adb push <filename> /sbin/

Do this for each of the six files (e2fsck, mke2fs, parted, resize2fs, sdparted, tune2fs).

Next, make them useable by changing their permissions: Use:

adb shell

to start navigating the file structure within the phone. You will see:


Navigate using linux commands now, and enter the sbin directory by typing:

cd sbin


chmod 0755 <filename>

on each of the sdparted commands you pushed into that directory. Now the parted command will work when you go to run it on the phone within the adb shell environment.

This is a very good place to slow down and BE VERY CAREFUL! You are about to run commands that will alter the partioning of the phone’s internal memory. You might very well make things worse unintentionally if you get sloppy here. I cannot promise that what you are about to do won’t TOTALLY BRICK your phone. I got mine back again, but your milage may vary, and lead you down that highway to hell.

I knew at this point that the information I’d found and was working from didn’t precisely match what I had been seeing in my phone’s error messages, or in information I looked at within my phone. Mostly, the partition file names were a bit different, and as I’d said before, that guy was talking about have wrong filetypes specified in his structure, and that didn’t seem to be my exact problem.

At this point you need to be sure of the correct device block names of your /data and /cache partitions, and maybe your /sd-ext partition, too. You can find out by doing this:

cd /etc

cat fstab

This will print out the partition structure in your phone. The lines that matter are those referencing the suspected bad partitions. The suspect partitions are the ones you’ve been seeing in your error messages on failed nandroid recovery attempts. For me those were, I think:

/dev/block/mmcblk0p1 /data auto rw

/dev/block/mmcblk0p2 /cache auto rw

It’s possible that the /sd-ext partition needed the parted command, too, but my notes and memory are incomplete here and I’m not exactly sure what I changed. Too, I’m guessing that the structure of the memory in the phone was changed again when I succeeded in running nandroid recovery after these steps, so for your situation let the error messages you’ve been getting be your guide. Less is generally more, when it comes to tinkering with re-partitioning. BE THOUGHTFUL AND BE CAREFUL.

The main thing is, I wouldn’t re-partition anything that wasn’t reporting a mounting error or formatting error of some sort as you were trying to get nandroid to do its thing.

Take a deep breath, and run:

parted /dev/block/mmxblkx mkfs ext2

using the block identifier that you think needs fixing. Leave off the “p” part of it. It will ask if you want to continue, hit yes. Then it will ask for the partition number: For me, I entered: 1. Next it might ask for the format, and enter: ext2 . Just as the author of the thread did, I needed to repeat this sequence for the second partition on the same block, like so:

parted /dev/block/mmxblkx mkfs ext2

Do you want to continue? -Yes

It asked me what partion number, and I entered: 2 , and it asked for the format, and I again entered: ext2 .

Now, you type:


and that takes you out of the adb shell.

  1. At this point, you are ready to re-attempt the nandroid recovery of your previous working android version. Make sure the backup files are on the sd card in the phone. I disconnected my phone from the desktop system, and rebooted into HBOOT, and then clockworkmod recovery in the usual way. Then followed the menu to “backup/restore” , “restore”, and chose the image of the system I’d saved that morning: -2013-01-27.55/ I pressed the button, confirmed my choice, and set it in motion.

And it worked!

I sincerely hope these notes will help someone out of a frustrating situation. At this point, I have notions of what I might try if I re-attempt to install Jelly Bean, but I’m a little gun-shy, and in no hurry to waste an entire day again with a broken phone. From what I’ve read, I do think the old ADR6300 can be made to run Jelly Bean, but it would be very wise to update ClockworkMod Recovery to something more recent first. That’s my best guess.

If anyone reading this has any insight as to why my partitons got screwed up from what I did with Jelly Bean, I’d be really glad to know. Please leave comments.