In 15+ years of building and maintaining SWIFT-connected systems that run SWIFT-provided software, I’ve never encountered a situation where a SWIFT message has “just disappeared”.
Actually, it's imposed by the institutions in the middle of the transaction as well.
Australian banks don't handle Icelandic krona, and Icelandic banks don't handle Australian dollars. As a result, they pick a third bank that handles both to be the middle man. If there's no one bank that handle both then it becomes a 4-player game. Every bank involved charges fees. I don't know how many banks get involved in AU->IS, but since the fee per bank seems to be about $15-$20AU as a standard, I'm guessing at least 4.
CD ripping. Initial audio pass in an older version of EAC, which hands off to the scripts. Those validate the audio against the AccurateRip + CUETools databases and file the rip appropriately if there's a failure (e.g. "might be a different pressing" vs. "few enough bad samples to be repairable" vs. "completely aborted the rip", etc.). Then a second pass on the disc to extract subcode data and embed any TOC/subcode differences as comments in the cuesheet. Then, based on that, automatically generate a de-emphasized version for discs with the PRE flag set anywhere, then extract additional metadata (full release date, disc number, featured artists) from the title data I manually entered in EAC, compress to FLAC, embed the cuesheet, transcode .m4a copies, and file.
Automatically adding sort-artist fields to the cuesheet/.m4a files is next (I have a good source in the software that I use for cataloging the collection). I also need to write something that backports changes made to the tags in the .m4a files to the original cuesheet...
The pro-open-plan side is armed with hard numbers; cost-per-employee for one buildout vs. another is easy to measure up front. The anti-open-plan side has no way of generating the equivalent numbers for lost productivity and even their best attempts at estimating them (relying on studies, etc.) are vulnerable to being dismissed as "just guessing". Hard numbers win over soft numbers.
Uh, no. Bit-perfect ripping is trivial and routine, and tools like the AccurateRip DB (which has checksums for around three million different titles you can use to verify the checksums on your own rips) and the CUEtools database (which has recovery records you can use to correct bit errors on your own rips) prove it. I routinely get bit-accurate single-pass high-speed rips--no "paranoid" settings or re-reads--of discs dating back thirty years or more, and so do hundreds of thousands of other people. If you get different checksums on successive rips of the same CD, either the disc is damaged or the drive you're using is failing.
Oh sure, your rips may be perfect at the bit level, but how do you know that they're free of sub-bit quantization that isn't detectable by electronic circuits but can be heard by the human ear?
This sub-bit jitter and interference can travel along with a digital file and sneak right past your ordinary bit-level error detection and correction, no matter how lossless you make it. That's because these errors aren't visible in the bits. They occur at a deeper and more subtle level, in between the bits.
Even if you prove mathematically that two files contain the exact same bits, you can't prove that the human ear won't hear any difference, can you?
Ah, well, the human ear is a much more finely tuned instrument than your decoders and players. Think of the feelings you get when you hear the ocean waves, the birds sing, a thunderclap!
Can you turn this into mere "bits"? Of course not!
That's why it is so important to protect against sub-bit quantization errors, and this can only be done with proper interconnects. Ordinary cables allow the bits to travel willy-nilly until they jam up against each other creating a brittle, edgy soundstage. Quality interconnects are tuned, aligned, and harmonically shielded to keep those precious bits - and the all-important spaces between them - in a smooth flow.
And then, we can hear all of the things that make us human.
Interesting. I'll have to check those projects out. I have the same problem as the GP -- I have a script that rips CDs, taking multiple reads until it gets two bit-for-bit identical copies. And just about every time at least one track is silently "corrupted."
(I put the scare quotes on because I haven't actually bothered to check if there is an audible difference. But it does confirm the GP's experience.)
I saw this implemented at (I think) Times Square Tower a few years back. It had you enter your floor at a podium in the main lobby on the way to the elevators, and it worked beautifully. 49 floors and not once did I have to wait more than ten or 15 seconds for an elevator.
Then they retrofitted a similar system back at my corp HQ. It had you enter your floor on a screen on the wall right in the middle of the elevator lobby and it was (and is) kind of a pain in the ass...because when there's a crush of people waiting for the elevators, you can't get to the screen to enter your floor. When it was just the "up" and "down" buttons in the same location, the odds were pretty good that someone in the crush had already pushed the button you need, but...
