That's a lot of Audio
The Bible is a big book. With 1,189 chapters, it takes 4,200 minutes to read it aloud. At Dwell, we're recording each of these 4,200 minutes four times, once with each of our talented voice artists (with more to come)!
Once these raw recordings have been created our talented editors and producers clean up the audio, pulling together the best parts of each take, and mix it down into one single Master Recording.
Each Master Recording is one chapter of the Bible. With 1,189 chapters and four voice artists, we have 4,756 Master Recording files that we need to store and manipulate.
This isn't just a lot of files, it's a huge amount of data. Our Master Recordings are mixed down to 24bit stereo wav files (44.1 kHz sampling rate). An audio file in this format takes up about 950 megabytes of data per hour. All told, that ends up at about 44.5 gigabytes per artist, or 177.8 gigabytes total (with a lot more to come).
The problem that we are faced with is this: How do we upload, store, manage, and deliver 180 GB of audio data to listeners all over the world?
Like any large problem, the solution is to break it up into smaller problems, and solve each of those.
Each Master Recording represents a single chapter of the Bible, which means that the average file is about 75MB. While still large, these are files of a size we can handle.
We take each Master Recording, and upload it to our API server (we'll talk more about our API server in future articles). The API server handles marshalling the data to S3, Amazon's data hosting service, where our files are stored with 99.999999999% durability (this means we should expect to lose a file once every 10,000,000 years; hopefully that's good enough).
By breaking 44.5 GB per artist down into 1,189 individual recordings, and taking each of those and hosting them with a data service provider like Amazon, we start to have the pieces in place to deliver audio to our listeners using our app.
The next problem we need to solve is how to take a Master Recording that's 75MB per chapter and break it up into the smaller chunks (of smaller file size) so that we can deliver it to listeners with even the slowest internet connections.
How do we do that? Stay tuned, as that's what we'll cover next time.