I was posted onto a live audio gig last week where I got to use an elderly Yamaha 01V for the first time in about 8 years. Initially I had misgivings given how old the board is (launched in 1998 according to Wikipedia – tallies with memory) and how long it had been since I’d faced one in anger. As setup commenced I was pleasantly surprised at how easy it was to mix on this machine. Sure, I only had five live inputs to deal with, so it wasn’t exactly a full band mix; but I did need to pinch out two monitor mixes from house position.
I found myself quickly remembering where everything is, and some cute foibles about getting into the EQ and using more patience than with more modern desks, as quick adjustments on the rotary encoders often got misinterpreted and intended cuts come out as boosts, or vice-versa.
So how did it sound? Well, once I reminded myself of how the pre-amps can be rather noisy and sorted my gain structure out a little, my impression was that it sounded a little more harsh than more modern digital mixers. I didn’t seem to need nearly as much gain on the pre-amps as I’m used to with other systems, and I had to be careful too because there doesn’t seem to be as much headroom in the main mix bus as I’d been used to. But the compression and EQ all did what they were supposed to, and even the on-board reverb sounded surprisingly good with a few tweaks here and there to warm it up a bit.
In the indoor confines of a darkened sound booth, the monochrome LCD was a joy to use too – I could see it at pretty much any normal angle and didn’t struggle to read it at all.
Flipping between layers to set main, monitor and effects mixes was a pleasure, as was the continual access to the “Return 1” ON/OFF button so I could switch off the reverb when the artist talked rather than sang. All the moving faders jumped to their correct positions without fuss – a testament to build quality and good hygiene by previous users!
All in all I was surprised at how little I actually focussed on the machine and just got on with the job. The raw simplicity of the device compared with the workflow of, say, a Behringer X32 compact to get the same work done was striking – I think other manufacturers could learn a lot from those early days of keeping key things available at a single button-push.
It’s amazing how far we’ve come since the launch of the 01V in terms of raw sound quality and user-interfacing, but I was stunned at how genuinely useful this board was in a real-world gigging situation. I won’t let the thought of using one scare me again, so long as it’s been reasonably well looked after.
I’ve been a fan of the Volumio Project for rather a while now, since discovering it as a good platform for my Raspberry Pi audio player a year or more ago. Several self-built MPD-based setups have come and gone since the Raspberry Pi arrived, but Volumio has been the mainstay for reliable playback with control from numerous devices. The main draw for me has been the combination of its web interface, the fact the hard work has been done for me in terms of getting all the software components working together, and the fact that the whole package does seem to sound good.
On reflection I’m not sure that the various “audio optimizations” at the kernel or any other level really make an audible difference, but I do know that the whole package does seem to work more reliably on the limited resources of Raspberry Pi hardware than anything I’ve been able to cook up myself, at least without significant effort expended.
So why does an x86 port excite me so much? Two reasons:
More processing power availability opens the platform up to interesting things like DSP and dual-use such as streaming to remote machines and the like without falling over. Presently I’d have multiple Raspberry Pi’s set up with dedicated tasks. That’s been educational, but arguably a lot of hassle to set up and maintain. A single machine would make some of this stuff easier.
Opening up the platform to more common (and more powerful) hardware fvastly extends the range of audio and storage hardware that can usefully be used with it, and perhaps extends Volumio’s exposure on the wider marketplace.
The Raspberry Pi is an amazing platform for what it is – and audio systems based upon its limited bus bandwidth are capable of sounding incredible. But not everyone has a NAS to throw their music onto, which makes the Pi’s USB2 storage a pain to deal with when using it for networking, local storage AND the audio device all at the same time. And even those two do use it with a NAS are hampered by the 100MB Ethernet connection. Sure, streaming even “HD” audio files won’t tax it, but storing, backing up and indexing large audio collections will. And THIS is where even an old Netbook could best it.
At some point where time allows, I’m looking forward to putting my elderly ASUS Netbook through its paces with a 192KHz-capable USB2 audio device and either a USB drive or “Gigabit” Ethernet adaptor (its own onboard Ethernet, like the Pi’s, is limited to 100MB), to see how it stacks up against the Pi running on the same hardware. I know from running the RC download today that the distro works and plays audio even on the onboard audio, and the default setup to use the onboard display, keyboard and mouse to show the Web interface by default is a lovely touch.
Really annoyed at Microsoft, on behalf of a Windows 7-using relative. They received an email on their Outlook.com address (formerly hotmail) on 30th June saying that they will lose access to some or all of their messages as of 30th June because they’re using Windows Live Mail 2012, and server upgrades require them to immediately upgrade to Windows 10.
Thing is, they only just understand what they have now. And they’re in the middle of a larger life project, for which cutting off email access RIGHT NOW with no more than SAME-DAY notice would effectively kill the project stone-dead and potentially leave them in a *terrible* financial mess.
Sure, as the email from MS points out, they *could* continue to collect emails from the web client until the upgrade has been completed. But that’s *another* thing to learn at a time when they’re least able to put time or mental power in to processing that kind of change.
From a technical perspective it really annoys me that a simple email service needs sufficient upgrades both to server and OS/client just to deliver electronic mail, for which standards for doing this sufficiently securely and efficiently have existed for *years* now, and seem to be followed by just about every other service provider on the planet. Even Apple’s iCloud service I *think* has eventually got over itself and eventually allowed standard IMAP login from non-Apple clients.
We’ll work out a solution – but this whole thing leaves a very bitter taste in the meantime, especially for those of us who just need to coach our users to get things done, because they don’t have the time and brain-space to keep pace with *everything* going on in tech world and why it’s shaped that way.
We in tech world would do well to put the users and tasks first for a change.
The long-running archiving project has hit a significant milestone – I’ve now digitised as much of the physical media as I can. Limits are set now by condition of the incoming media, and whether or not it’s really worth digitising 4 or more decaying copies of the same thing when we already have better copies of the same thing elsewhere. The only reel (!) exception is a set of reels for a particular project whose magnetic layer fell off as soon as the reels were unpacked. No way is that worth spending money to preserve further given the age, obscurity and potential value of the content, not least the hardware value to retrieve it once the media itself has been restored. Shame, but commercial sense has to come into it somewhere along the line.
Now have a DIY automated process for holding an in-DAW mix (working in REAPER) at -23dBLUFS or thereabouts, which greatly simplifies things for radio and podcast production. Even if I only use it for monitoring or other less critical work, it’s an amazing time-saving tool.
Obviously this means it can be adapted for -16dBLUFS or any other value as needed.
It’s *really* not pretty for a number of reasons – most bothersome to me is that it presently works in stepped values, somewhere around 10 updates per second – rather than more smoothly applying gain or attenuation.
For high-end stuff, I’m still happy to do final levelling by hand as it does tend to sound better, but that does add time to any given project.
I’ve been using lossless audio compression as a matter of course in my audio workflow for a while, and not just for end-distribution. Services like Bandcamp and Soundcloud support uploading in FLAC format, and many clients happily accept ALAC (Apple Lossless) or FLAC in place of traditional uncompressed WAV or AIFF formats.
As for long-term storage and archiving, I’ve switched to FLAC for my projects, and have back-converted most of my catalogue. But why FLAC?
The reduction in network bandwidth and storage requirements is always nice.
It brings the possibility of checking the project audio files for errors via the FLAC checkum (applied at the time of creation) against how the file decompresses in present-day.
This can show up problems with “bit-rot” on disk storage that would otherwise remain hidden. It’s a useful alternative to deploying ZFS-based file systems and keeps storage and network kit at an affordable “prosumer” level while such technologies mature a little longer, and hopefully come down in cost too.
If I find a problem file? Fine – restore from a good backup. But that does rely of course on having good backups, and the corruption not being carried into those!
It’s an established format that many, many software applications can read, across a wide variety of operating systems – and given the number of websites springing up offering “audiophile” digital transfers of consumer audio material based upon the format, I have good confidence that software to read and write to the format will continue to be developed for some years ahead. And if not, it’s still easy enough to batch-convert files to whatever format replaces it.
Cons (none unique to FLAC, I notice):
Reaper is my DAW of choice, and exporting large projects out to FLAC is time-consuming as it still doesn’t multithread FLAC exports for projects.
While Reaper *does* support (in version 5.111, at last check) recording directly to FLAC and other formats, recording to anything other than WAV or AIFF on my systems has consistently thrown up audible glitches in the recorded material. With some sample-accurate editing these can be fixed, but still not acceptable.
What I do therefore is to record to WAV/AIFF first, then save the project to FLAC before any significant mix down happens.
Not every DAW supports FLAC natively, or at all. But then, for me this is a moot point – not every DAW can read project files from every other DAW, so this is just a part of that wider picture. You pick your tool for the job and deal with the consequences.
Conversion takes time, especially offline for large projects.
So – that’s a quick brain-dump of how I’m working with this stuff and why. I’ve missed steps and I’m sure others will be quick to pick holes in it.
I suppose my question to anyone else reading this with sufficient interest is… What is everyone else doing? What file format would you pick, and why?
I’ve been using my Revox B77 with various audio interfaces and operating systems for a while, and this week I’ve restarted tape imports for a long-running project that needs to come to a final conclusion – at least on the ingest stage.
Various factors, not least compatibility with Mac OS X El Capitan, have forced me into using my Presonus Firestudio Project as the analogue-to-digital converter for this stage. It’s not ideal for a number of reasons, but it gets a job done, without too many sonic compromises (especially when compared with the vagaries of the source material) and so I suck it up and move on with life.
One important thing has come to light this time around though… My B77 *really* doesn’t like feeding Channels 1&2 at line-level, which are labelled as “instrument” (presumably Hi-Z, high impedance) inputs. Its output preamplifier runs out of headroom rather quickly and ends up giving horrible clipping, especially with the outputs wound up to give something approximating “line level”.
Plugging into any other channel line input (3 through 8) does reduce the recorded signal level as seen by the DAW software, but also gets rid of this clipping. Lesson learned.
I’m left wondering if this is an expected quirk of the B77 electronics, or whether it’s a quirk of my specific machine? I don’t (yet) have time to go poring through manuals to find out for sure – but I can’t say this result surprises me!