iTunes makes broken MP3 files now?!

I've always stuck with MP3 files for music because it is the only format that everything we've ever owned will play. Currently we've all got iPhones and iPods but the car machine is one of those no-name head-units that's a radio and a flash-memory player. In the past we've had an assortment of 'phones and no-brand MP3 players and so I think the choice I made back in the late nineties to start moving all my music to MP3 was valid.

People object to MP3s for one of two reasons;

• It's not an open format like OGG Vorbis - it's notionally "owned" by Technicolor. It is so ubiquitous that I suspect they'd have problems enforcing that.
• It's lossy, and not even the best example of a lossy codec.

As ever Wikipedia has a very comprehensive article. On the first point I think life is too short to get all religious about technology choices. In the case of documents formats - sure; send RTFs rather than DOCXs just for politeness (actually, both formats belong to Microsoft!). Not everyone has the right machine or can afford MS Office (oh, and NEVER send Open Office specific files!).

In terms of the lossy nature of MP3s I'd say that if you encode files well yourself it shouldn't matter for most people and most music. With very little effort you can get MP3s that are so close to the uncompressed data that came off the CD that you'll never know. Audiophiles (who still tolerate all the noise and 2nd order harmonics that come off vinyl - and don't get me started on the RIAA characteristic!) claim that no compression is good, but I suspect they do so for reasons of fashion or self-aggrandisement. The reason I say that is I have actually done the tests!

Back in 1999 I was involved in a project to transfer a large audio sound effects library to a server. The start of the project was to see how well compressed audio was suited to the task. Drives were small and expensive back then and so the success of the project rested one us using compression. So - we compressed several dozen bits of audio to 96, 128, 160, 192, 256kbits/sec;

• Spoken word - properly recorded in a high end audio booth for existing TV voice-overs, male & female.
• Music - a selection of acoustic, classical, rock etc
• Sound effects - from the BBC library, spot effects as well as longer ones (bird song etc)

So these were blind-played to the Oasis Television audio staff (at the time a good example of "golden ears" - people who have been trained to hear audio problems) in properly built audio suites (£10k speaker systems in acoustically dead rooms). So - not amateurs making judgements on sub-£1,000 domestic rigs, but a proper blind-test using professionals.

What we discovered was that past 256kBits/sec nobody could get reliably better than 50% correct - it was as good as if they were guessing which was compressed and which was uncompressed. This seems to fly in the face of current opinion that says that even 320kBit/sec is detectable on iPod earbuds (!) - and don't forget that the LAME and Fraunhofer compressors (reckoned to be the best) have been getting better over the last decade-and-a-half (particularly with respect to VBR encoding).

Lots of people also suggest that other codecs (particularly AAC and WMV) are now better than MP3; I've never been able to hear that when I've compared like-for-like (data rate, VBR vs CBR etc) and since MP3 is so ubiquitous it seems likely that manufacturers would have spent more dollars optimising it that any of those lesser used codecs?

So - I compress my music to 192kBits/sec using the LAME VBR setting and I rarely hear an artefact. There are a few albums I did back in 1999 that I've gone back to because modern compressors are so much better and the little MP3 player I had back then could only hold a complete CD at 128kBits! The cruel irony is now that I know what I'm listening for and can (just about!) afford decent speakers my hearing response is rolling off quite markedly. Pretty soon AM radio will sound good. I've also found that when I mix live music I drive the high-end a lot more than I used to and that must be the same effect.

There is another effect that people talk about - how tired you get listening to compressed audio - the brain doesn't like artefacts that you don't encounter in nature. I think this is true, but the people who make play of it tend to be vinyl & FM radio fans - both of which are covered in very unnatural artefacts.

So - to the point of the post; I discovered that a couple of CDs encoded by iTunes over the last year wouldn't play off a USB stick in the car. I had to re-encode them on the old AltoMP3 maker software I used to use. flailing around online seems to suggest it's the way Apple sticks artwork in.

The Engineers Bench podcast - shared storage for film & TV

Hugh and Phil are joined by Rupert Watson from root6 to talk about SANs, NASs and shared storage for film and TV. Find it on iTunes, vanilla RSS, YouTube or the show notes website.

Shared storage for film & TV - the next podcast

Hugh and Phil are joined by Rupert Watson from root6 to talk about SANs, NASs and shared storage for film and TV - see the wiki

The end of Television Centre - what's changed since I was there?

I joined the Beeb in 1988 and spent the first five years of my career in and around TV Centre. My first BBC posting was to Lime Grove studios (which was a few hundred metres behind the centre) with the occasional foray up to Studio 2 to do camera control on Newsnight. 

Although it's now twenty years since I worked for the BBC I still hold the corporation in great fondness for training me and always encouraging best practice from an engineering point of view. I don't think I could have had a better start in the industry. I honestly believe the BBC is a civilizing force and an example of just how good and truthful a broadcaster can be. They are without equal in my view.

Anyhow - just a few notes on how things have changed since 1988;

Videotape - 2", 1" and 1/2" BetaSP (just coming in) and UMatic or even VHS for offline and viewing copies. Since I worked in news some footage arrived on UMaticSP - BVU900 style.

Digital Video - when I started there was very little equipment that was digital; even less so that was run by a microprocessor. PCs were never seen as everything was built for the purpose (and cost £100k as a consequence!). Aside from D1 videotape (that was still very much being demo'ed at trade shows) you found digital video inside equipment, not used to interconnect it;

• TBCs - Timebase Correctors for analogue videotape - typically a few lines of 4Fsc storage
• Frame Synchronisers - used to time free-running incomming feeds into a studio
• DVEs - typically three frames of storage that would allow you to re-size or at best 'curve' a video signal
• Painting system - only Quantel Paintbox 7001 series at the Beeb but there were others - Spaceward Matisse was the competitor.

Audio - still mostly analogue recorded on 1/4" or 1" 24-track (Studer style). DAT was starting to come in and there was Sony F1 for sending stereo digital audio over a video channel. We also had SIS (Sound in Syncs) - a way of sending digital audio on a video signal. NICAM had just been launched (14-bit, 32Kits/sec companded to 10-bits = 728kbit/sec) - I hadn't heard of audio compression at this point!

Video Cable - at the BBC this was either PSF1/3 or PSF1/2 for long runs; oh, when we expected so little from coax!

Studios - This is a picture of Studio 2 from 1988

Notice the Grass Valley GVG-1600 vision mixer - it's the one you see in Star Wars in the Death Star controlling the destruction of Alderan!

Notice the VT100 terminal at the left hand side of the desk; that was connected to the BASYS newsroom network running on six PDP-11/84s (IIRC) and controlled scripts, the AutoScript prompters and even gave us all email.

The DVE was a Quantel 5000 that occupied a whole equipment bay!

Cameras - they were all tube cameras when I started with the attendant headache calibrating them for a studio shoot and they required two engineers to control them - one for the "racks" (blacks and whites) and one for colour control (referred to in the Beeb as "knobbing" - I did that a lot!). The cameras shown here are a pair of Link 110s from my time at Line Grove. We had Link 125s in TC2 - they were all a nightmare! When I moved to Carlton in 1993 I was amazed how good the Sony BVP-7 CCD cameras were to line-up and control.

I don't have a whole load of photos from the time; we didn't have cell 'phone or digital cameras and I have a feeling it wasn't considered good manners to take photos at work. I do have a picture from 1992 from the big wall of Stage 5 (which was under construction pretty much the whole time I was in News VT maintenance in the Spur).

This wall was subsequently obscured by Stage 6 which was built in the nineties.

In summary there is no other place a trainee engineer could get experience of:

• Studios
• Post Production
• Outside Broadcast
• Telecine
• Transmission

Trainee engineers of 1988!

Fixed the DVI / pin-16 hotplug dilemma

As with a lot of mod'ing or (dare I say it!) bodging solutions you need to find a nice connector or pre-made cable to base your fix on. If you look back at the problem we've been having with Media Composers switched across different Amulet heads then you'll recall it wasn't an EDID issue, rather one of Windows detecting a monitor change; Amulet does the right thing, it's Avid that's the problem.

The fix is easy; you need to tie pin-16 (hot plug detect) to Vcc (+5v on pin 14) via a 1K resistor;

The best mod'able pre-made cable that is suitable is one of these from Lindy.  Now I just need to knock up a dozen for the customer!

AES audio on D-25 connectors

I've been working at a facility that delivers DCP masters to cinemas and the thing that we had to pay lots of attention to is the pinouts for various multi-channel audio servers and monitoring boxes, principally;

• Dolby 650 & 750 surround processors - the gadgets that "tame" a room to make it sound like a cinema or screening environment should
• TC Electronic TM09 multi-channel monitors; used for loudness monitoring (R128 & ITU.1770)
• Dolby DS100 & 200 servers
• Doremi DCP2000 servers

They are all different!

I could just list all the pinouts from the manuals but here are a couple of grabs from cable schedules that show exactly how to do it over DMP-10 cable, krone blocks etc.

Odyssey Products have a great PDF summerising them

 

PING goes further than you think

Do you ever need a quick and free method of testing the reliable uptime of a network server? There are lots of paid for bits of software and onine services but if you have a spare Windows box this little DOS command (which you can save as a .BAT file for quick deployment) does a superb job;

cmd.exe /v:on /c "FOR /L %i in (1,0,2) do @ping -n 1 10.100.100.241  | find "Request timed out">NUL && (echo !date! !time! >> PingFail.txt) & ping -n 2 127.0.0.1>NUL"

Make sure that if you cut'n'paste it you edit out any inserted line-breaks.

Inside of our FOR loop is where we really get to the meat. We've basically got 4 steps:

1. First we see @ping -n 1 10.100.100.241 The @ symbol says to hide the echo of the command to the screen. The switch (-n 1) says to only ping the IP once. And of course 10.100.100.241 is the address we want to ping (at home it's my media machine)
2. Next we pipe the results of our ping into the FIND command and search for "Request timed out" to see if the ping failed. The last part of that >NUL says to dump the output from this command into NUL, because we don't really need to see it.
3. Now we get fancy. The && says to only run this command if the previous command succeeded. In other words, if our FIND command finds the text, which means our ping failed, then we run this command. And we've enclosed this command in parenthesis contain it as a single command. We need to use the "cmd.exe /v:on /c" command at the beginning to allow for delayed environment variable expansion; that way our time & date changes each iteration. So %date% and %time% becomes !date! and !time!.
4. And finally we're redirecting our output to a file called PingFail.txt. We use the >> operator append each new entry rather than overwrite with just >.
5. And finally we're on to the last step. As mentioned before, the & says to run the next command no matter what has already happened. This command simply pings localhost with (-n 2) which will give us a one-second delay. The first ping happens immediately, and the second ping happens after one second. This slows down our original ping back in step 1 which would otherwise fire off like a machine gun as fast as the FOR loop can go. Lastly, we're redirecting the output with >NUL because we don't care to see it.