[Tim Jones]

The big win here is to get the user to understand that the compression used for DATA is not the same as compression used for transcoding. Transcoding is a lossy (on purpose) type of operation. We know that when we transcode a file to another format, bitrate, etc., that we will lose data. The compression used for DATA is lossless – meaning that you get 100% of what you put in back after compression and decompression. And, LTO-‘s mechanism is adaptive in that if the algorithm cannot compress the data (which is true with most M&E content), it passes the data through to the tape uncompressed, anyway.

Imagine if your bank backed up your records to LTO and when they had to restore your data, you now only had $3.00 in your account instead of $3,000. That definitely would not pass any form of use, security, or standards examination.

You will never lose fidelity or content allowing the tape drive to manage the compression automatically. We (the tape industry) created it to operate that way on purpose.

[Tim Jones]

We’re getting close. The Black Friday through Christmas sales stymied the efforts to get things crossed over, but they’re now on track for a January re-launch.

[Tim Jones]

Why not reorganize your work folder layout to match the layout on the server? It’s a “Since the mountain won’t come to Marina, Marina will go to the Mountain” situation.

[Tim Jones]

<div>I’d just like some straightforward “BUY THIS” suggestions.</div><div>

In that case, and if you’re willing to make the PC move, grab an HPE Z series workstation, load CentOS Linux and really run rings around things. Don’t be afraid of Linux since it’s the best of both macOS and Windows and given the same hardware, my 16.2.7 Studio runs around 25%-20% faster under Linux than under Windows 10.

</div>

[Tim Jones]

Hi Jan,

Those will continue to work fine – you simply need an appropriate Type-C to USB-3 Type A dongle:
https://eshop.macsales.com/item/OWC/TCCADPU3/

or

https://www.amazon.com/JSAUX-Adapter-Compatible-MacBook-Samsung/dp/B07BS8SRWH

[Tim Jones]

Running the 17.0 beta here on my Intel Mac under Catalina and it’s pretty sweet (also on Linux). I don’t expect to see any developer abandoning the Intel platform for many years (if ever). Even Apple’s not abandoning Intel and the existing Mac Pro and friends are still shipping for a while.

Also, just because things have progressed, the older versions don’t just stop working. Some friends are still running Final Cut Pro 7 …

[Tim Jones]

In case you missed it, the BRU technologies and products are being brought under the OWC banner.

[Tim Jones]

Yes, we will be honoring all existing support contracts with the 3 months of down time honored, as well. We haven’t started yet as I need to get the teams up to speed.

[Tim Jones]

First – I’m happy to announce that BRU and the various TOLIS solutions are not dead. I also apologize for going dark for these 2 months, but we were working on a new opportunity that will make everyone happy. Please stand by for more info in an announcement this week.

To Bob Z – careful, friend, doxing is a felony, and what you were promoting above about our phone numbers is doxing.

To Jim – I know that Marcos and Eric provided these steps to you previously in support, but here they are again for posterity:

Each BRU Archive is written with a buffer size that you select when you start using the product. In order to restore data from a tapeset, you need to use that same buffer size. This is what you were running into above, and here are the steps for sorting things completely from a Terminal session:

[code]

# Rewind and get the buffer size of the tape:
tapectl rewind
tapectl header | bru -gf –

# that will return the header for the tape in the drive. In it
# look for the bufsize: line. That is your buffer size to use for
# the restore. For example, if your line read:
# bufsize: 132078
# you would pass that number (or divide by 1024) to the -b argument:

tapectl rewind
bru -tvvvvf ntape0 -b 132078

# This will resolve the read error on first block.

# To restore to a mounted array, cd into the restore location and then
# pass the -PA argument to the restore line to tell BRU to restore in
# non-absolute path mode:

tapectl rewind
cd /Volumes/MyArrray/MyRestoreFolder
bru -xvvvvf ntape0 -b 132078 -PA

# You will see the data filenames displayed as they are resstored to your
# mounted array.

[/code]

To Everyone – hang in there and we’ll be back up to speed very soon.

Tim

[Tim Jones]

Hi John,

Not a casualty, just a slightly sick user :). BRU’s not dead and we’ve brought it and our solutions under the banner of a very well known organization. Look for the announcement this week.

Tim