As I mentioned in part 1, the WSH and some VBScript can be used to do more than move files around. Another use is in parsing the data in files. Parsing text files is very easy to do, but there are no built-in functions for accessing binary data. You will find, however, that others have made up for this shortcoming by implementing their own classes for manipulating binary files. See for example this site with example code. This example uses only VBScript code to create a Binary Object class, although better performance is achieved using dll's or COM objects. However, for the purposes of my demonstration, I used the CBin.vbs code in the tsbin.zip file at the above site. If you would like to run my demo script, you will have to download this zip archive and put the CBin.vbs file in the same folder as the script when you run it. My example pulls a list of wav files from a given folder and reads the binary file header and prints out the CartChunk Content Depot data. One could use this information for making scripted decisions about when to copy or move files or perhaps to push the future XML pad information in the file to a database for a "Now Playing" or other application. Currently, I don't have any other good uses for this script besides reporting what is there, but maybe it is useful to you. Maybe you could use it to email someone when a new file shows up. I would love to hear some more ideas. So, without further ado, here is my code for your perusal.
ConDepReader_v1_0_1.zip
UPDATE (2/22/2007): After reading some posts on Pubtech lamenting the lack of a spreadsheet of CutIDs, I updated the script (now v1.0.1) to output a report of files and CutIDs in CSV format for use in Excel or whatever.
Tuesday, February 20, 2007
Your WSH is my command, part 2
Posted by
John McMellen
at
3:38 PM
0
comments
Labels: contentdepot, scripting, vbscript, windows
Tuesday, January 30, 2007
Your WSH is my command, part 1
Several recent projects converged on a single need to automate basic server tasks, such as synchronizing folder contents, media conversion, etc. My first priority was to pull special "promo" audio files off of our Content Depot storage receiver and put them in another safe location so that our staff could edit them or otherwise use them in their spot production without having to navigate the critical parts of the storage receiver file system. The Windows Scripting Host (WSH) is ideally suited to automating such tasks. It is installed on every Windows XP and Server computer, is easily scripted and very powerful. In fact, there are several useful scripts included on your installation in the System32 directory, scripts that can automate printer management and filter event logs. I know what you're thinking, though. "VBS files are bad! They are viruses! That's why Norton blocks them!" They can be used by attackers, commonly in email, but are very useful for many Windows tasks. The Microsoft Technet journal carries a regular column called "Scripting Guys" that details many excellent scripting uses. You can also find VB scripts at the heart of the Samurize desktop widget software.
On to the fun stuff, though. As I mentioned, I wanted to get promos off of the storage receiver and into another folder on a different computer where they could be safely operated on. Using VBScript and the WSH, I created a list of files in the source location that match a regular expression, check that they are newer than files in the destination or don't exist in the destination location and copy them. This script then runs on an interval using "Scheduled Tasks" in Control Panel. I also found that using the command line Mplayer software, I could automate the conversion of these files to uncompressed wav files in the destination. Sweet! Lastly, I check to see if there are any files in the destination that aren't in the source location. These are deleted from the destination and walah! We are synchronized!
This type of scripting would also be useful for retrieving many other types of files from the storage receiver, items like images, rundowns, etc. that at this time are locked away because no one wants their staff monkeying around in that folder looking for these files. They could be automatically emailed or pushed to a web server or content management system for use. The WSH makes it easy to automate.
I am including a link to my script for your examination. In part 2, I will show you how I used a script to retrieve and report on the Cartchunk data stored in the wav files.
PromoSyncConv_v1_1.zip
MSDN Reference Material for WSH
Posted by
John McMellen
at
2:01 PM
0
comments
Labels: contentdepot, scripting, vbscript, windows
Tuesday, December 12, 2006
Syncing computers to Content Depot
Here are some resources on syncing computers to Content Depot with NTP.
Microsoft pages showing how to configure Windows Time service to use the Content Depot receiver as an NTP source.
Windows XP
http://support.microsoft.com/kb/314054/
Windows 2000
http://support.microsoft.com/kb/216734/
I posted previously about using the Meinberg NTP software to monitor the Content Depot devices NTP servers to indicate if they were working or not. Meinberg NTP can also be used to sync to them.
I am trying the Beagle Software ClockCard with ClockWatch Server to sync our NexGen audio server to Content Depot. So far it looks very accurate and should not drift if there are large amounts of time that we cannot synchronize. I also have some indications that NexGen provides native support for the card. I am looking into it.
Some are also using the Dimension 4 NTP client. I have not tried it, but others really like it.
Lastly, some have mentioned a program called About Time. Again, I have not tried that one, plus, it looks like older software, not updated in a while.
Tags: radio networking ntp content depot
Posted by
John McMellen
at
12:52 PM
0
comments
Labels: contentdepot, networking, ntp, radio
Wednesday, August 23, 2006
More details on half-duplex networking with Moseley Starlink with LAN option
I wrote this in an email to a colleague who asked how I tested our network connection over our Starlink STL. I wanted to save it for future reference.
----------------------------------------------------------
Ah, I have not tried using NetCat on Win98. Thanks for the tip. I just pinged myself over UDP on my XP box. On one command prompt, I ran the program like this:
nc.exe -u -L -p 5002
On a second command prompt window, I ran the program like this:
echo "Hello World" ¦ nc.exe -u 127.0.0.1 5002
This printed out the text "Hello World" on my first command window. This should work the same between two computers on a LAN.
Now, there is one small snag that I hit with the Moseley Starlink LAN port. Forgive me if I am repeating something you are already familiar with. On a normal network (full duplex), when a host wants to open a connection to a destination IP address, it first has to turn that IP address into an Ethernet MAC address (192.168.0.1 ==> 00:01:de:74:2a:07 for instance). To do this, it uses a protocol called ARP. It sends a broadcast message out that says "Who has [dest ip]? Tell [host address]." Then, when the dest computer hears its address asked for, it sends a reply to the requesting computer. The original host who made the request then caches the address and finishes its connection. The problem for the Starlink is that a destination computer on the receive side can never send an ARP reply back to the computer that asked for it, so no hosts on the transmit side can ever figure out on their own what the MAC addresses are on the receive side, hence they can never generate any packets to send. So, the network administrator has to set up his switch or the computer that wants to send packets over the Starlink manually with the MAC information for the computers on the receive side. In Windows, for example, if you know the IP address and MAC address of a computer on the receive side of the Starlink, you can put this information into a computer on the transmit side of the Starlink with this command:
arp -s ip_address mac_address
This will add a static entry into this computer's ARP table so that it never has to ask for the address. It just knows what it is and makes the packet and away it goes. There are also commands for Cisco switches to help this situation too, but I would have to look them up.
To answer your second question, I have tested our Starlink connection. I actually used a program called VLC to encode an audio file as a stream and it sent the data using UDP to a computer on the other end running VLC as a client. I posted a link to VLC on my blog but I didn't have time then to go into detail. You might read a little about VLC and see if it something you want to try.
Tags: radio networking HD Radio
Posted by
John McMellen
at
9:27 PM
0
comments
Labels: HD Radio, networking, radio
Friday, August 18, 2006
Online debate about the future of HD Radio
Start here and work backwards.
A lot of really good points are made. What I benefitted from is a reminder that the real thing thing that listeners are interested in is content. The project really has just begun when the digital transmitter is installed. The biggest investment of effort will inevitably be in developing more content or perhaps new features that will make consumption easier. Also, any efforts toward generating new or existing content should take advantage of Internet distribution as well.
Tags: radio media digital HD Radio
Wednesday, August 16, 2006
Satellite radio faces economic difficulties
I read this article in the Wall Street Journal (mentioned here) about a potential financial crisis facing satellite radio companies. It seemed to highlight to me that terrestrial broadcasting's strength continues to be that it is free and hopefully stations will use their HD Radio multicast capability to offer interesting new content instead of more of what is already available in their markets.
Technorati tags: radio satellite digital HD Radio
Tuesday, August 08, 2006
Thoughts on what radio is good for
I had a very interesting meeting today about how we would plan to use the new technologies that are emerging to offer new services. I have been thinking a lot lately about what radio can do well in this new world we live in. Google and other search engines have dramatically changed how we are informed. In the old days, if you wanted to know about something, you would tune in and find out. Or if you wanted to hear a piece of music, you would tune in and listen, maybe even make a request. Now, search has made it possible to find almost anything you are looking for and you can usually download it and listen or watch it on your own time. This is natural and much more efficient. I could imagine fewer and fewer people listening to radio for this purpose. However, as the saying goes, "You know what you know, and you know what you don't know, but you don't know what you don't know." This is something I try hard to remember because no amount of searching for something will educate you on how much you don't know. We need other people to tell us things about things we don't already know, things that are interesting or entertaining. They can help us discover new styles of music or information that we didn't know we didn't know. I can't think of a better way to do that than broadcasting. I hope that broadcasting of the future will involve more of a two way interchange between broadcasters and the communities they serve.
Tags: radio media search hdradio
Posted by
John McMellen
at
3:48 PM
0
comments
Wednesday, July 05, 2006
Verifying communication over a unidirectional IP path
A fellow engineer asked today about how to ping from one side of a one-way network connection to the other to make sure it worked. I thought I would post some ideas that I had found when I was trying to do the same thing.
The ping command would work, but only if you had some network monitoring software on the device on the other end that you were pinging because the ICMP echo replies can't get back to the pinging host. An Ibiquity document describes how to overcome this using some utilities supplied with their HD Radio equipment on pages 64 and 65 of this document.
In addition, one could also run NetCat on two computers, one sending data on intervals on one side and the other listening for data on the other side. There are Windows versions of Netcat available with a quick google search.
My personal favorite method was to set up VLC on one computer streaming some audio or video to the other side on a computer running VLC as the client.
Tags: radio engineering network hdradio
Posted by
John McMellen
at
12:54 PM
0
comments
Wednesday, June 21, 2006
Using tickets to maintain a station operation
I have posted before about using ticket creation software to track repairs, changes and other tasks done by engineering. A couple of months ago an engineer on Pubtech posted a link to the RequestTracker homepage in reference to how his shop keeps records and organizes these support tasks using a ticket based process. Once I got a chance to install and configure this package I was amazed at how useful it was just to improve my own record keeping and organization. It was not too hard to install, was free, and is fairly simple to use. Rich, you deserve a great big thank you for pointing this software out.
The most exciting possibility I have envisioned for us is the possibility of handling some problems in a more automated way. For instance, RT can be set up with an email gateway so that you can send an email and it will automatically record it and then act upon it however you choose. So I was thinking, wouldn't it be cool if I could have my equipment send an email to the RT software to report a problem and then the server would in turn open a ticket and forward the problem on to me by the most logical method. If it was a severe problem, it could be programmed to forward to my cell phone by text message. If it was less severe, it could just forward to my normal email inbox or possibly wait in the queue on the server for someone to act on it. This handles the problem of how do you process and forward all the alarm information from all the new devices that are capable of sending electronic alerts (remote controls, Content Depot, automation systems, etc.) in an intelligent fashion while preserving and documenting the history of these problems. I need to learn more about the scripting features in order to accomplish this, though, and try to find time between satellite equipment upgrades, HD Radio upgrades and everything else to try it out. I think it would be really cool.
Tags: radio engineering ticket
Posted by
John McMellen
at
2:03 PM
0
comments
Friday, April 21, 2006
NTP service monitor
I found this utility while researching the NTP service that will be available on our new PRSS Content Depot receivers. It can monitor a local NTP service or external ones, and can email you if they are not functioning. This might be useful for knowing if our Content Depot devices develop any problems and warning us.
Posted by
John McMellen
at
3:47 PM
1 comments
Thursday, March 16, 2006
Why does Windows rename things?
Actually, it is a security feature. I am talking about the extensions of files downloaded from the Internet. The reason it is a good thing is that if the MIME type is an audio file and the extension is exe, then guess what happens when your browser gets the file? It may likely just go ahead an run an executable program that you thought was an audio file. However, Windows does make some stupid assumptions about what extensions a file type may have. Our radio station has been downloading audio segments from the Public Radio Satellite System's Content Depot. The files are MPEG 1 Layer 2 (extension .mp2) files. The server sends them as MIME type audio/mpeg which Windows assumes is an MP3 file, so it automatically changes the extension to MP3. Frustrating. I found this workaround by digging in the registry. Under this key, "HKEY_CLASSES_ROOT\MIME\Database\Content Type\audio/mpeg", delete the value "Extension". After restarting IE and Firefox, both browsers left the extension mp2.
Posted by
John McMellen
at
1:07 PM
0
comments
Tuesday, February 07, 2006
Taming runaway processes
This free utility claims to be able to dynamically adjust the priority of processes based on how much CPU is in use. Sounds useful, but maybe a little dangerous. I would like to try it.
Posted by
John McMellen
at
10:20 AM
0
comments
Tuesday, January 24, 2006
Content management
Our Grad Assistant has been working on our content management system. This homegrown application has become more and more important in our operation. It is a new idea for radio. What we used to think of as a content management system was our automation system and all it did was put audio on the air. But now, you have web streaming, podcasting, online archives, RSS, and more in the works. The next big area to simplify our operation will be to create the capability to create content once and have the servers distribute it in whatever media you want. I wonder if the automation system vendors are working on this too?
Posted by
John McMellen
at
10:47 AM
0
comments
Audio over Ethernet
Broadcasters are beginning to see the value of building Ethernet networks into their physical plant. In the past these networks were used for file based audio playout and automation, but now more streaming audio is being delivered over the network. Appliances such as the Axia Livewire system and Audioscience Cobranet do this in hardware. I have found that for quick setup of audio streaming across a local network, VLC is a useful, free program that fits a variety of situations. The executable acts as both a server and a client. It allows you to do traditional http streaming, but also offers more advanced options using Real Time Streaming Protocol (RTSP) or UDP streaming. It even offers multicast streaming. I believe it could even capture audio streams off of NPR's Content Depot network. I hope to get to try it soon that way. UDP streaming is also very useful for one-way Ethernet connections from Studio to Transmitter.
Posted by
John McMellen
at
10:37 AM
0
comments
Wednesday, October 26, 2005
HD Radio Importer options
There are more options available now when it comes to purchasing an Importer for HD Radio transmission. Prophet Systems has an Importer installation that integrates into their NexGen software and allows multiple streams and will send PAD to both Main and Secondary Audio services. This will be helpful to us in planning our upcoming digital radio project.
Posted by
John McMellen
at
2:58 PM
1 comments
Tuesday, September 13, 2005
Instant Messaging
For the first time, I am seriously using IM. It all started when I installed the Google Talk client and messaged some of my family that I had sent Gmail invitations to. After reading about the client and network, I found that it uses the Jabber protocol for the IM portion. I had heard of Jabber before, but never got around to using it. My first thought was: Could I use this open-standards based messaging protocol for secure, encrypted communication with people in the office, say, during fundraiser time? Google led me to the GAIM project, an open source, free IM client for many platforms and services. This client also has two different plugins available for encrypting text communication between endpoints. It can work on Google Talk, AIM, MSN, Yahoo, and a slew of other services simultaneously. And since it works with the Jabber protocol, I can setup a Jabber server on Windows or Linux and do it all in house if I want. At the moment I am using GAIM to chat with developers at Prophet Systems while I beta test some new software and I can chat with everyone else at the station using their preferred service wherever they are. I also found software that will connect an automated program to a Jabber network (they call these bots) and use it to get information about various things. As more stations get "now playing" information from their systems, I can see that a listener could have your station as a buddy in his IM client and ask it questions about what is on, or it could send a message to people who want to know what's coming up. It will be much easier once this station data is all encapsulated in XML. For now though, my next project will be to set up a Jabber server for fundraiser. Who knows what will come after that?
Posted by
John McMellen
at
11:13 AM
0
comments
New podcast software
We are beta testing a new podcast module for our automation system. The software is called "Pod XLR8R". It looks like it will make it very easy for radio stations to generate podcasts using the same production processes as they use for normal operations. I am looking forward to using the software to podcast some of our locally produced programs.
Posted by
John McMellen
at
10:46 AM
0
comments
Monday, August 15, 2005
Finding the time
Reminder to self: work in some time to update the blog.
Posted by
John McMellen
at
11:49 AM
0
comments
Monday, June 27, 2005
Podcasting + mobile wifi = New radio?
An interesting research project sponsored by a major car manufacturer that has been talked about in the blog world.
http://www.roadcasting.org/finalDesign.html
It would take a long time to match the market share of broadcast radio, but it is still a neat idea.
Posted by
John McMellen
at
8:21 AM
0
comments
Friday, June 24, 2005
Multichannel audio over existing delivery infrastructure
After doing a lot of research about various digital multichannel formats, I found that there are a few MPEG standards already for multichannel audio files. The most intriguing to me from a practical standpoint is the MPEG2 standard. NPR uses MPEG1 Layer2 for audio files delivered over Content Depot at 256 kbps. The MPEG2 Layer2 audio stream is backwards compatible with the MPEG1 Layer2 stream but allow additional channels of audio to be sent in the stream. An MPEG1 decoder will playback the multichannel file as a regular two channel stereo file while an MPEG2 decoder will play all the channels, giving you discrete multichannel audio delivery. I have not had time or proper test material to do rigorous testing, but I think it is a neat idea. I found that these two tools allowed me to create a multichannel MP2 file from 6 single channel WAV files that could be derived using a multichannel mix bus in software (Sony Vegas) or hardware (mix board with sub-outs).
First is a Microsoft utility that will put many single channel WAV files into one container. This tool actually uses AVI as a container because the file size can be greater than 4GB, unlike WAV files.
Then, I have used Hypercube Transcoder to create a multichannel MPEG2 Layer2 audio file that can be played back on any computer. If the computer supports multichannel MPEG it will produce 5.1 channel sound. Otherwise it is just stereo.
Posted by
John McMellen
at
1:39 PM
0
comments