Music & Media files in the age of Blockchain & what we can learn from shipping containers.

A lesson from history:

The shipping technique known as “break-bulk cargo” was the only method of freighting goods around the globe until the 1950s. This system required deliveries of sacks, barrels and crates to be stored on the docks for days before a ship’s departure when they would then be loaded individually.

Photograph by Lewis Hine c. 1912

Because there was no standardized size or shape of parcels, these items were an inefficient use of surface area storage both onshore and ondeck. Loading items individually was also time consuming, so expensive labor forces of longshoremen were required to make fast work of loading the ship. Imagine moving to a new city, but loading the moving truck with each individual item from your house instead of first placing them in individual marked boxes. The load-in and load-out times would be exponentially increased unless you bribed a number of friends to help with the work.

In the 1950s, everything changed. Standardized container shipping, while not the first, was arguably popularized by the maiden voyage of the SS Ideal X on April 26, 1956. Aboard the vessel were 58 factory pre-loaded and identically-sized cargo containers, each with a designated truck awaiting anchor at the other side. The lower cost (both in time and money) was immediately apparent using this new system of loading. Three years later, the first dedicated quayside container crane was introduced, further increasing efficiency and reducing labor cost. In essence, the containers’ standard size allowed for every factory, fulfillment warehouse, freight company (truck, train, boat, and plane) to quickly and safely transport goods, regardless of whether contents were different shapes and sizes. Most importantly, standardization allowed for rapid movement of goods owned by multiple parties and there was a staggering 780% increase in commerce.

So, what can the music industry learn from shipping containers?

Thus far, the music industry has treated audio files alone as the core digital product to be “shipped.” Metadata, while crucial, is an ancillary delivery to merchants and is sent as a separate file. Much like a lone barrel going missing on a cargo ship, without a container, these two important deliveries might not be in sync. We also know that ownership data can change over time: writers sell their shares, labels or publishers may acquire or sell catalog, co-writers may be added, and territories may change. Today these changes are tracked in proprietary centralized databases to be updated over time by large authoritative bodies. So, as digital media consumption scales, the challenge becomes: how do you keep all that information in sync among stakeholders and DSPs?

Just like our sacks, barrels and wooden crate cargo before the 1950s, our digital music files can find themselves in many non-standardized forms (.wav, .mp3, .flac, .xml, .xls, etc.). This becomes further complicated if preferred formats change as the file travels between factories (DAWs, labels and publishers), warehouses and fulfillment centers (distributors), and merchants (DSPs).

Without a standardized shipping container, it is both time consuming and expensive (think back to our overworked dockside longshoremen) to track down who owns which disparate parcels. It is also more challenging for destination merchants (DSPs) to know what goods they are receiving and who they should be paying. Currently, DSPs must rely on DDEX and CWR data provided to them in any number of non-standardized delivery methods: XML, private Microsoft XL/Google Sheets databases, and yes even faxes are sometimes still involved(!)

Although DSPs have the computational power to sort through and deliver goods at speed (think of our cranes, and standardized trucks) they aren’t receiving goods in a way that allows them to work efficiently. In other words, the containers they receive don’t fit on their trucks, so they can’t use their cranes (the machine that can save the work of many human hands) to do the work quickly and at low cost. So how can we work smarter, not harder, as an industry?

Imagine Dot Blockchain Media as a digital shipping container:

Let’s say 50% of the container contains the information of who wrote the song (publishing) and the other 50% contains who performed the song (recording).

Then, imagine within that very same container (now “owned” by multiple parties), you were able to sync metadata, ownership information, licensing information and the audio file itself.

This Dot Blockchain Media digital shipping container (.bc or “dotBC”) creates a protocol for the music industry that enables tracking, communication, and monetization of audio files at a fraction of the time and cost.

Just as a shipping container holds goods for multiple vendors, Dot Blockchain Media uses blockchain technology as a synchronizing agent for audio files and data with multi-party ownership. Most importantly, Dot Blockchain Media’s protocol can give songs dashboards, that allow for inter-party communication and fast resolutions to changes in song ownership going forward.

Dot Blockchain Media is NOT a new media format, it is also NOT a way of paying artists in cryptocurrency.

Dot Blockchain Media is a way to synchronize data across all stakeholders in the music industry from the indie artist or songwriter to the largest major label and streaming service. Thus increasing efficiency and reducing cost for all parties involved in the delivery, storage, and updating of audio files and their data.

Blockchain technology used in this way will allow for the music industry to scale the way ISO shipping containers allowed the cargo industry to scale rapidly (and that 780% growth would certainly be nice, right?).

For more information on this topic you can watch the keynote presentation from The Next Web below, or you can visit our website: www.dotblockchainmedia.com

[VIDEO]

Like what you read? Give Benji Rogers a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.