Our community, the Dawoodi Bohras have a rich and varied oral tradition which is expressed in the forms of qasidas, marthiyas, naats, munajaats and the recital of Quran-e-Majeed. Over the years, we have tried to aggregate examples of our oral tradition and made them available at our audio site.

On our audio site, at present we request samples to be made available in WAV format. We would really prefer any loseless encoding instead of WAV whether its FLAC, WavPack, Monkeys Audio and many others.

Please understand that formats like MP3, AAC (Advanced Audio Codec, used in iPods) and Windows Media Audio are known as lossy codecs in the sense that they lose some information from the original CD recording in order to be able to compress the file to approx 10% of the original size. They use lots of fancy algorithms to create the perception that the sound is as close to the original as possible.

But nobody in their right mind would use a lossy encoding as their master source, hence the requirement of loseless codec which as their name suggests do not lose any information yet are able to compress the original file size albeit to only about 50% of the original size.

In terms of delivering our content, we provide at times two links one named ‘Download’, the other named ‘Listen’. Frankly, from a user experience point of view this is not right. The intent is to ‘listen’ always so what does ‘download’ indicate. It’s primarily historical. The content team wanted to provide what in the industry is known as ’streaming’. That’s what the ‘Listen’ link intention is. Users would click on the link and their player would launch and play the file whereas with the ‘Download’ link would just download the file on the users desktop.

With todays proliferation of freely available media players and their tight integration with web browsers the ‘Download’ link really doesn’t work since it too launches the player and plays the file.

True streaming refers to the ability to play audio as the data is coming in over the network so one doesn’t have to wait for the entire download. We really don’t do true streaming, since if you observe carefully we generate a .RAM file which is a real-audio metafile that points to the .rm file.

We also serve this file via the HTTP protocol. Delivering Real Audio files over HTTP has quite a few limitations including one that requires the entire content be downloaded before it can be played and if someone has the illusion that it prevents the content to be stored on the end user machine then that person should not complain when their DRM intentions are bypassed

In order to do true streaming, we would need to setup a streaming server such as the Helix Server, Quicktime Streaming Server or Windows Media Server.

Users would like the ability to store the audio/video content we provide locally so they can listen to it without needing the ability to be connected to our server. The ‘Listen’ link we currently provide is an anachronism.

In a future post, we’ll discuss some interesting ideas on delivering large content rapidly to a userbase.