Useful Consumer Review

I’ve been filming some concerts the last year or so.  I’ve been using mostly normal compact cameras, and they work quite well.  The Sony RX 100 II is probably the best one of the bunch.

However, they either stop filming after 30 minutes because of tax reasons (apparently, in the EU there’s an additional tax on film cameras that can be avoided if it’s “not really” a film camera), or the battery runs out after 30 minutes.

Or both.

So it was suggested to me that I might want to look into using a real video camera, and the Blackmagic Pocket Cinema Camera is supposed to be pretty spiffy.  It has a big sensor or something.  I dunno.

DSC01601The first attempt didn’t work so well.  The built-in microphone red-lines quite easily, even at the lowest sensitivity.  So concerts are just square waves of BZZZZB KNKNK  BZZKN.

I finally bought some small external microphones and tested them the other…  month.

DSC01603And with that mike, it the audio comes out fine.

The battery life isn’t all that awesome, though.  I get about 50 minutes on one battery, so I have to carry extras.  And on the higher quality settings it generates a lot of data, to put it mildly, so using a 128GB SD card is required.  Unless you want to shuffle SD cards all evening.

Then I noticed that the video looked all washed out and dull.  After some googling, that’s apparently a feature.  The camera doesn’t do white balancing or normalisation or anything.  To leave you (i.e., me, the film professional) with as much detail as possible, everything is kinda grey and boring.

Fixing that is apparently called “colour correction”, and I’ve watched tutorials on that this evening.  There’s a number of packages under Linux that purports to help out here, but I couldn’t get Kdenlive to work.  Cinelerra wants to recode everything upon opening, which takes hours.  The same with Kino.  And daVinci didn’t want to install at all.

DSC01600

But I did manage to get Lightworks to install and work, and it’s pretty fast and nice.  Although incredibly confusing.  I’ve played around with various colour corrections.  Here’s one where I went black-and-white with high contrast:

(Note my fabulous “put the camera on the table and then keep on drinking beer” camera technique.)

And here’s one where I just tried to make the white bits less white, but add more contrast:

Oops.  I should have increased the audio sensitivity on that one…

Lightworks transcodes to a format that Youtube doesn’t need to transcode, so uploading after colour-correction is quite fast.

In conclusion:  I think things are too complicated.

Useful Consumer Review: A Correction

After discovering that Logitech wireless things work much better if I don’t plug the receiver directly into the computer (because science), it reminded me of another Logitech device that I’d dismissed earlier: The Logitech Cube.

And by using an USB extension cord, it, too, has an acceptable range, so I could actually use it for something…  if I figured out what I could use it for.

I mean, it only generates two keystrokes:

DSC01598Page Up if you hold it this way and click…

DSC01597
I should trim my nails

And Page Down if you hold it this way and click.

Or the other way around.  I forget.

If you just put it on a table and click on it, it decides that it wants to be a mouse instead, so the click turns into a mouse click, which is definitely not what I want.

Hm…  but I do have gaffa tape.  I wonder what’ll happen if I just gaffa the sensor on the bottom.

DSC01599
Elegant!

It works!  So it can be used as a single purpose HID button.  If I had something where that would be useful, and that didn’t use the Page Down key for something else.

Or… I could perhaps just use the event remapper thing from the previous post, come to think of it.  But I don’t really have any projects that would require such a button right now, so back into the Cupboard Of Mystery it goes again.

I apologise for besmirching Logitech’s, er, good? name.

Linux, X and Logitech

I’ve had a Logitech diNovo Mini as my TV computer keyboard for a few years.  It works as well as you’d suspect a wireless keyboard to work: It loses contact with the receiver a couple of times a month and needs to be switched off and then on again, but otherwise it’s OK.  Doesn’t lose too many keystrokes.

DSC01590
Logitech diNovo Mini

But it’s starting to fail mechanically, I think.  The larger buttons (Enter, Del, etc) now only work if I press them…  just…  so…

I looked around for new media keyboards, but they’re either too big, or unusably small.  This was kinda just right.  So I went off to eBay and got a couple of new old ones.

At least that’s what I thought I bought.  Instead I got a couple of Lenovo TV730 keyboards, which is apparently also called Logitech Mini Controller.

DSC01591
Logitech TV730

See?  Very similar.

And here my troubles began.  This Logitech came with a different, smaller receiver:

DSC01592
Much small

The receiver works fine under Linux, but I could only get about two meters range.  (That’s seven microfurloughs in Imperial measurements, I think.)  But I had it plugged in like this:

DSC01593
I should wash those grease stains off the front

After bitching about this on IRC a bit, I tried using an USB extension cord.  Like this:

DSC01594
Very finger

And then I got, like, an 11 meter range, through two (pretty light) walls!  So the metal in the computer case messed up those radio signals or something?  Ok, we’re on!  This is doable!

And then I discovered that some of the keys don’t work in Xorg.  In particular, the PgUp and PgDown keys give exactly zero X events, according to xev.  That’s no fun.

I fired up the ever-useful evrouter utility:

quimbies:~# evrouter -f -d /dev/input/event*
"Logitech TV730" "/dev/input/event9" none key/402 "fill this in!"
"Logitech TV730" "/dev/input/event9" none key/403 "fill this in!"

key/402?  That’s a suspiciously high number.  And duckgoing around shows that this is a well-known ancient X problem: X can’t deal with events that has a numerical value over 255.

This was reported as a bug at least as early as 2007, and apparently they (sort of) started working on it.  But they didn’t fix it.  Instead this very nice person wrote a simpler fix that allows you to just remap these problematic keystrokes into other keystrokes.  Yes, it’s a hack, but if you’re not going to provide a real solution in 8 years, I think it might be better to just include the hack, don’t you think?

Obviously the Xorg people didn’t, so you still have to build your own evdev_drv.so.  The link up there has good instructions on how to build and install this driver into your X, so I won’t repeat that.

For my device, I put the following into my /etc/X11/xorg.conf:

Section "InputDevice"
 Identifier "Logitec TV730"
 Driver "evdev"
 Option "Device" "/dev/input/tv730"
 Option "event_key_remap" "402=112 403=117"
EndSection

This remaps the weird PgUp/PgDown keystrokes into the normal ones.

To get the device to show up under that name, I put the following into my udev setup.  This is with the current Debian; your mileage will vary.

quimbies:~# cat /etc/udev/rules.d/10-tv730.rules
ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c52b", SYMLINK+="input/tv730"

However, it’s not totally unproblematic.  If I pull the receiver out and then put it back in again, X will sometimes not believe that it’s been inserted:

[3275248.027] (**) Logitech TV730: Applying InputClass "evdev keyboard catchall"
[3275248.027] (II) Using input driver 'evdev' for 'Logitech TV730'
[3275248.027] (**) Logitech TV730: always reports core events
[3275248.027] (**) evdev: Logitech TV730: Device: "/dev/input/event9"
[3275248.027] (WW) evdev: Logitech TV730: device file is duplicate. Ignoring.
[3275248.032] (EE) PreInit returned 8 for "Logitech TV730"

So…

Youtube and “unsupported device” redux

I posted yesterday about my extremely useful Youtube-based weather monitor not working properly any more.  I thought Google had changed the video format or something — refusing to play videos when using mplayer.

After adding more debugging to the script that runs the monitor, that turned out to be incorrect.

Here’s the search result for a song by Dollboy:

Searching for Dollboy+The%20Ventriloquist (200)
Duration: 236 (https://youtube.com/devicesupport)
Duration: 232 (Puppet Dancing in South Africa)
Duration: 324 (Ventriloquist Dummy Creepy Doll Makeup Tutorial)
Duration: 449 (Creepy Broken Doll: Hair, Makeup, and Costume Tutorial!)

One of the results in the search is the “unsupported device” video!  And my script would pick that video if it’s the one that has the most appropriate duration.  And it seems to be in the result set for any searches:

[larsi@potato ~]$ ./src/flutter/flutter "" "foo"
Searching for foo (200)
Duration: 245 (Foo Fighters - In The Clear)
Duration: 236 (https://youtube.com/devicesupport)
Duration: 271 (Foo Fighters - The Pretender)

So this is just Google’s way of saying that their old search API is being phased out?  I’m using the

https://gdata.youtube.com/feeds/api/videos?q=$search&max-results=10&v=2

API.  And this seems to be the case: The API v2 is being discontinued.  The v3 API requires an application ID, and it’s more JSON-ey, but it looks like it should provide the same functionality as the v2 API.

It’s nice of Google to notify the users of the v2 API that this is happening, I guess, but it would have been nice if the video said something about the API instead of just saying that the device was unsupported.

mplayer, Youtube and “unsupported device”

I’ve been using youtube for really useful things for a few years.  On April 20th, the following video started to appear instead of the ones I wanted:

I get this for about one third of the videos — the rest play fine, as before.

So it’s saying that I’m viewing Yotube with an unsupported device.  Which is probably fair enough.  I’m searching youtube via the API, getting an URL via youtube-dl, and then playing the video with mplayer under Linux.  Neither really sounds like what Google would call a supported device.

Devices affected: Select devices manufactured in 2012 and earlier, including Sony TVs & Blu-ray Discs, Panasonic TVs & Blu-ray Discs, older iOS devices, and devices running older versions of Google TV.

So Google says that three year old TVs are too ancient to watch their content.  Fine.  Who cares about three year old TVs, anyway?

But does anybody know how to make mplayer support whatever the new format is?  Or is this part of Google’s ever present drive to wall their gardens?

I’ve binged for an answer, but haven’t found anything promising…

Edit: The problem seems to be with the search API, not mplayer.

The Effect of Version Control Systems on Emacs Developers

In November 2014, Emacs switched version control systems from Bazaar (aka bzr) to git.  There were two main reasons: 1) bzr has kinda stopped development, and 2) using a version control system that more people are familiar with might attract more developers.

On the other hand, git is really, really finicky, and bzr is arguably superior to git in many works flows. Perhaps switching to git would scare away some Emacs developers who just couldn’t be bothered?

It’s now April 2015, so five months have passed, and I whipped up a teensy script to tally the number of patch authors per month, and then plotted the results.

The red line denotes the changeover.

First of all, it’s amusing that we have a timeline going back to 1988, but I would suspect that the numbers before, say, 2007 are too low because maintainers would commit patches with themselves as the “author”, I think.  (Edit: Eli Zaretskii says the numbers should be accurate throughout the timeline.)

But the most recent years should be kinda reliable:

Uhm…  Well, attracting droves of new developers didn’t happen, apparently.  Except for the spike the month git was introduced, we’re within the normal range of developers, I think.

Anything interesting pop up if we count commits per month instead of contributors per month?

Not really — same story.

What about the number of people who commit patches to the Emacs repository?

That does look like a possible uptick.

So…  was the changeover worth it?  Probably.  But the impact was a bit over-sold on both sides, I think.

Emacs and id3

I rip all CDs, vinyl and cassettes to flac for easier listening, but I also convert the files to mp3 for listening in the car, which has an mp3 CD player.  This is what the display normally looks like:

DSC01582But all the files that I’ve ripped from vinyl are displayed like this:

DSC01583I’ve been assuming that my vinyl ripping tool chain just hasn’t been inserting id3 tags into the mp3 files for years, and that the car mp3 player was just displaying random data.  But yesterday I finally remembered to check the tool chain, and it does insert id3 tags into those files, too.

So, while pondering this deeply serious and puzzling issue, I started looking at id3 tools.  I wanted one that could just output all the id3 data in a machine-readable format, so that I could, perhaps, figure out what it was about certain files that made the car stereo not like them.

And I couldn’t find a single one.  I installed at least five different ones, and they were all so charmingly human oriented.  Phooey.

id3-2If I managed to discover what the problem was, I was going to have to re-tag all the problematic mp3 files, and I wanted that to be a process that could be automated, so I need machine-readable output.

Instead of continuing down that rabbit hole, I just wrote an id3 parser in Emacs instead.  And what the problem was because obvious on the first file I parsed:

id3-1The group name starts with “\377\376M^@”…  That’s utf-16 (or ucs-2) with a Byte Order Mark!

Interpreted as the iso-8859-1 Latin-1 charset, that would just be “ÿþM”, because it would think the string terminated at the first nul byte.

D’oh.

So the version of the Lame mp3 encoder on my vinyl ripping computer writes utf-16 tags, while the CD ripping computer writes iso-8859-1 tags.  And my car only understands the latter.

Mystery solved.

But when I’ve written the id3 parser, I thought I could just finish the job and write an id3 mode, too, to allow viewing and editing the id3 data.  It’s a bit scary, altering the mp3 files themselves, so I’d handle this with care.  In fact, I would recommend not actually testing this mode for writing data.  But it kinda seems to work for me.  Slightly.

Here’s what it looks like on an mp3 file that has an embedded image inside:

id3-3Kinda basic, but should be a starting point if somebody wants to experiment more…