Posts Tagged ‘player’

Recording multiple FM radio stations (works for AM, too)

Tuesday, December 27th, 2011

As it seems, we in media monitoring want to record everything.  Good part of everything is still in FM radio spectrum (or AM in some flat-land countries).  An usually, there are plenty of stations on the air that we have to record, at least a dozen at a given location…

Ancient history

Many many years ago, when I was working in FirePlay (great radio automation company and software) we had a task to produce a recorder that would record ONE channel of radio program 24/7.  At that time, encoding MP3 in real-time was some kind of science, and wasn’t available but on most advanced systems that were available (I won’t try to be exact here, but it was something on the lines of Pentium 133Mhz).

So we build FireSave, first version, that was able to handle 1 channel and record it to hard drive, encoded in mp3 format.  We even tried to use some obscure GSM codecs to save space even more…

Ancient history, but without dinosaurs

Setup above required live external tuner to be connected to the Sound Blaster (yeah, really).  We had some multi-channel cards but they were expensive, and using them to record a confidence and/or compliance recording would be waste of money.

Our need was expanded from one channel to several, say 4.  Since we had some expertise running multiple channels, we quickly added more external tuners, replaced Sound Blaster with some multi-channel monster (it was Wave4, then Gina24, then other stuff from EchoAudio, such as Layla 3G) and finally upgraded the software so it could handle multiple channels.

It worked, with 4 external tuners attached to one PC, sometimes more, it looked like an octopus.

Present days (year 2009)

OK, but what if you need and want to record 150 radio station that typical country like Croatia has?  You’ll be able to get some audio cards that will have up to 16 audio inputs (even mono sound will be OK), but to have that kind of external tuners, that is and could provide some kind of a problem.  And yet still, they can’t all be heard in one place, so you’ll have to have multiple recording sites in order to capture everything you need.

Or not?

The simple fact is that every good radio station will have its internet stream so it will be heard on the internet.  And there is a way to capture that stream of the internet and save it to hard drive as you would record it.  There are multiple tools on the internet that would allow you to capture internet audio streams, and you just have to choose one of them, and you’ll be able to record any radio that has its stream.  Before we created StreamSink, I was extensively using StationRipper for my own purposes, and that was the inspiration that was needed to create very similar tool.  It is similar in the respect that it records internet audio (and video) streams, but one thing is very different: all ‘rippers’ including StationRipper are designed to try to cut audio stream at song boundaries, creating a library of songs for the user.  On the other side, our task was to create system to record internet streams in multiple formats in the archive format usable by VideoPhill Player.

It isn’t anything special – just a bunch of files named in some fashion and cut at every five minutes, with special care not to lose single byte of a stream while cutting it.

So with that system, recording 100 radio stations on a single computer is as simple as having an good internet connection present.  Of course, every stream will be recorded as reliably as the server and the internet permits, and there is nothing you can do about it.  When using that method, you must allow yourself to lose some of the archive sometimes, for the unforeseen facts.  Again – better radio stations (the stations that you will need 100% of the archive) will have better sources, better distribution servers, and thus your archive will be better covered.

Expected Archive Coverage

But what to do when there are NO streams?

Lately (Summer 2011), there was a client that needed to record multiple radio stations as well.  However, after initial investigation we concluded that radio stations that needed recording were either badly presented on the internet or not presented at all.  So instead of capturing streams, we were aiming to capture radio signal from the FM directly.  All we had was the antenna that was dipped in the airwaves that contained our radio stations (8 of them).

Strategy was as follows: I have a tool that can capture streams in the format that my application (the Player) needs, but we haven’t the streams.  Let’s create them.

Shoutcast internet radio is on the market for decades.  And it has both free and tremendous support, and their software for creating and distributing internet radio streams are as robust as they can be, since they are field tested in possibly millions of usage scenarios.

As I knew how to encode the stream, how to distribute it (locally) for the StreamSink, I just needed to capture FM signal somehow.  Using 8 external tuners would be funny for the client, and I’ll probably lose them, so I did a little digging and found a beauty in form of a PCI card:

Professional PCI tuner adapter

This little monster (AudioScience ASI8921) is able to capture 8 FM radio channels and give them to the rest of the system in the form of the DirectShow or waveIn API, just what we needed.  Only thing left to do is to connect the antenna to the card and configure shoutcast encoder/server as needed, turn on the StreamSink, and we are recording!

Having NAS is great (or is it?)

Saturday, December 17th, 2011

During the years I had many deliberations over the fact if either NAS would be used or it wouldn’t be used for the video archives created by video logger system such as VideoPhill Recorder.  At first, I was firm believer in one methodology, then completely turned my side to the other, and now, …  Well, read on, and I’ll take you through it.

Stakes

On the one side of the stake set we have actual requirements, and on the other there are considerations.  Actual requirement are sometimes hard to pinpoint at first, but they always come out sooner or later.

So, let me list possible requirements that might be in effect here…

Common low level requirements

Storage for video recording (for logging purposes) needs to have following abilities:

  • low but constant and sequential write rate – data rate for 4 channels are as low as 5mbit per second (500kbytes/sec) but is CONSTANT and SEQUENTIAL – there won’t be much stress for the hard drive because of constant seeking
  • high durability over time – what gets written once, has to be there.  It should survive single drive failure
  • reading isn’t common, but when done, it has to be sustainable, but again at low data-rate and great predictability (it usually is sequential)
From everything above, I can guess that any data storage expert would read RAID 5 and won’t allow you to create anything else for the video archive storage.

Archive duration scalability

The archive duration is directly proportional with the hard drive space that is available.  To determine what kind of hard drive space you need for your first installation, you can use on-line hard drive size estimator calculator that I created right for this blog.

If you plan extend the duration of your archive one day, you have this requirement, and you have to plan for it.  Having the storage at one place can simplify the adding of the drive space, but can also completely block it.

Let’s say that you have the archive of 40 channels that span 92 days (3 months).  And let’s say that you decided to use 1mbit video with 128 kbit audio for the archive.  By using the calculator above, you’ll find out that you have 42 terabytes of storage already in place.  Even at this date, that kind of storage set in one place is kind-of-a challenge to build.

If you have already invested in 42 TB storage system, and have foresight to plan for an upgrade to say its double size for it, you are in luck.  But, say that after a few more months (just 3) your management decides to expand the requirement to 12 months of storage.  Wow.  Now, you have to have 127 TB total.  If the current system will hold that much drive space, again you are in luck, however – say it doesn’t.  Your options are:

  • add one more to the chain
  • create a bigger unit, copy everything to it, scrape the current one
I’ll stop my train of thought here, and leave you only with few things to think about before I go on with other requirements: who needs used 82 TB system (if you want to sell it), do you know how much it is to COPY 82 TB even at extreme network speeds, adding one more will break the ‘all in one place’ requirement, …

Having it all in one place (i.e. for web publishing)

If you need everything in one place for the publishing, then this is a solid requirement.  Web server will have the content on its local hard drives, and it will publish it smoothly.

But, is that really a requirement?  I must admit that I didn’t see web server that properly served files from the network locations (despite the thing that there are option to do that), but I’m sure that IIS and Windows Server gurus will be able to shut me down and say that this is normal thing that is done routinely.  So, if we know that each channel recorder has its own directory ANYWAY, what’s the use of having

c:\archive\channel1
c:\archive\channel2
c:\archive\channel3

instead of

\\rec1\channel1
\\rec1\channel2
\\rec2\channel3

Reducing single point of failure

This requirement is very common, and having NAS system as a ‘point’ it brings us that having the NAS leads us to having single point of failure.  I understand that there are multiple redundancies that could be installed into the system, such as RAID 5, or obscene configurations such as RAID 1+5.  Note: for later, it seems that the article author has a same opinion on it as me:

Recommended Uses: Critical applications requiring very high fault tolerance. In my opinion, if you get to the point of needing this much fault tolerance this badly, you should be looking beyond RAID to remote mirroring, clustering or other redundant server setups; RAID 10 provides most of the benefits with better performance and lower cost. Not widely implemented.

In my words: if you need such system, it’s better to have recording drives distributed on each recording machine, have RAID 5 there, and additionally have NAS (or some other form of storage) to DUPLICATE everything.

Bandwidth issues

At a configuration with 4 channels recorded at one machine, and with above mentioned data rate for video and audio, each machine will produce 5 megabit of content every second.  Roughly, that is .5 megabyte.  Even ZIP drive could almost handle that.  However, if you have 10 times that (for 10 recorders) and have central storage for the whole bunch of channels, that is 5 megabytes of data at a constant rate that never stops.

Consider that central storage in question is NAS has hard drives configured in RAID 5.  That means that it will have to receive, calculate parity for, move the drive heads, write to drive, …  It will be very busy NAS, and with everything else in mind, it won’t have a second of a break.  Add to that occasional reading of the content from the archive diggers, and you’ll soon figure out that the NAS will have to take it all itself.

On the other hand, archive access applications such as VideoPhill Player doesn’t have anything against having the channels on different recorder machines.

Conclusion (for bandwidth issues) – having each recorder machine handle both encoding and storage for 4 channels will reduce single point of stress for both recording and the archive access.

Overall…

Having dumped my intuition in this few paragraphs, I hope that I presented case that is strong enough against having NAS for video logger/archive storage.  Again, everything said is from my experience on the subject, and I’m no storage expert who will talk petabytes, just a simple consultant trying to get my clients best bang for the buck.  Please, I won’t mind objections to the text, on the contrary…

 

Medianet visited

Tuesday, January 13th, 2009

In our continuing mission to find new customers and enable them to remove their VHS bases video archives, we found medianet.hr company.  They do their press-clipping and media-clipping work and they really need video, audio, and other types of archives.  So, we engaged to provide video services for them.

I can say that guys there were really interested in our work.  You can’t really know how motivating that is.  Their main concern is their enormous archive that goes several years in the past, and is stacked onto the shelves of their office.

One repeating issue was brought up on the meeting.  That is our renown DVD export for VideoPhill player.  So, with so many interested parties, it seems like we are obliged to make it.

On to the Internet we go…  to find something that will enable us to do so.  I can take two roads here: GPL road and fully commercial road.  One leads to ffmpeg with dvdflick (or parts of it), and other leads to MainConcept.

Also, something that has troubled me for many times, is that they pay massive fees annually to the company that provides software for video clip recognition.  Since that feature lies exactly on my interest path, I guess that I will try to hit that road also.  I am thinking that some basic clip recognition could be build, but to fully test it we’ll need massive archive.  So another curious task, to build one.  My flat/office already is starting to look like a hi-tech warehouse, who know where it will go from there.

And at the end – it’s now very clear that stream logger project that I started as a pet project needs to be produced commercially.  There really is a strong need for such a product, or a service that we could provide to them.  Again, to test it and develop it massive storage space should be provided.  I found out that Addonics has very interesting gadgets to that effect.  But their shipping is expensive, so I’ll wait some more until I will really need something big from them.