英夫美迪S1播出系统分析.doc

英夫美迪S1播出系统分析摘要：本文以英夫美迪S1播出系统为例，描述了播出系统的整体关系、S1config数据关系，对节目安排和节目播出的处理流程作全面剖析，对这套播出系统存在的问题进行探讨。关键字：音频工作站，S1,Air2000,播出系统，程序设计。 要分析播出系统，首先要知道播出业务人员安排和运作方式。一般电台的业务人员分为编辑人员、主持播出人员，系统维护人员。其运作方式：采编人员负责新闻及节目的采编，这部分工作通过编辑站的WorkRoom客户端软件完成，主持播出人员负责播出，包括录播、直播、临时资料查找播出，这部分工作通过放置在播出室的播出站完成。技术人员主要负责权限分配，保障播出系统正常运行。本文以英夫美迪的S1播出系统为例，以节目业务为核心作出系统分析，其他的广告、标头、资料处理与节目处理类似。下面给出S1播出系统整体关系图：一、 与编辑登陆相关数据表登陆程序主要完成工作：1对用户名、密码验证，查询用户及用户组的使用权限。2、通过查询S1config库下的AudioInfo、StarterBase、ProgramLibrary分别查找节目、标头、资料所存放的机器名及数据库名（其他类型音频库类似）。3、查询用户的存储区分配，以便用户把自己的音频资料放到自己的空间上，同时对使用空间进行查看。4、显示在播模板的节目单，包括版块、栏目和当日的所有播出音频条目。下面给出这四项工作所涉及的数据表及关系图：二、 资料录入模块数据处理资料来源可分为：CD、网上下载的其他格式的音频、自己录制的新闻节目，因为按广电总局的要求，播出网和外网是物理隔离的，那我们怎么和外界进行音频交换呢？我们采用英夫美迪的ICM连接线，在播出网和外网各设一台文件共享主机，只要把我们下载下来的音频放到共享文件夹，自动传送软件就会自动把文件转到另一个网。如果不是S48格式可采用格式转换软件进行转换。录音就采用CoolEdit、2496或者录制软件DAW录音。CD就采用抓轨的方式。运行编辑站软件WorkRoom编辑上单。主要完成的工作是：1、查询表area，提供可选存储区，用户选择节目存储区。2、根据存储区“areanum”+“最小空余audnum”组合成节目记录ID。3、填写该音频信息，上传本地的音频文件，生成“m”+“节目ID”+“.S48”作为音频文件名存到服务器的存储区。4、最后确定，记录入库。下面是WorkRoom中新建节目数据处理流程图：三、 编单程序流程编单就是安排已经录入的资料进行播出，涉及到播出的栏目，播出栏目决定播出方式和播出时间。下面以节目类型的音频资料为音源，给出编单处理的简明流程图：我们进入编辑站。通过查询节目库audioinfo1下的节目表program，可以查看到所有节目资料，选定其中一条记录，点击“申请播出”按钮，这时程序就会更新所选定记录的Applied字段值为“1”，点击“同意播出”时，Passed字段值为1，反之为0。当点击“安排播出”按钮时，先查询配置数据库S1config下的表P2U2Right，检查用户对该栏目的权限，然后在节目库audioinfo1下ProgramChannel记录该节目ID的播出日期、通道号。最后，在节目单数据库AL+年+channelid下ProgChange表增加记录，该记录有栏目、播出时间、播出站ID字段。四、 播出站程序设计播出客户端程序主要完成以下工作：1、 程序启动。启动播出程序air2000，先读取配置文件，根据配置访问S1config配置数据库，读取audioinfo、channel得到节目资料库和节目单库。2、 显示播出单。这个功能模块主要是结合MouldChannel、MouldBroudcast两表查询板块表mouldBlockVersion和栏目表mouldVersion。最后查询节目库得到当天节目单。3、 查询栏目更新。这块对应节目上单时的progchange,查询到有本机ID的栏目时，就刷新该栏目。4、 用户登录，这个功能块和编辑站的用户登录一样，主要是控制用户对栏目的操作权限，不再详述。5、 资料查找播出。这个功能块，实现对各类资料音频的查找和临时安排节目，主持人在播出站安排的节目是不入节目单数据库的，刷新的话会重新读取数据库的节目单。下面是播出程序设计流程图：五、 结束语我们可以看到S1播出系统符合我们的播出实际需求，给我们的工作带来很大方便，这套播出系统在很多省级广播电台使用多年，运行安全、稳定。同时，通过以上系统的分析，我们对音夫美迪的播出系统有个整体的把握，对每个功能模块的来龙去脉有了深入了了解以后，可以加强系统管理能力。如果遇到播出问题，可参照流程图对问题进行条理分析，快速找到问题的根本原因并解决问题。按照上面的系统分析可以进一步开发、改进播出系统。但是，它还存在很多缺陷，存在不足之处及可能的改进办法：1. 用户设置只能按台设置，假如一个编辑或管理员要使用多个台，那么就得每个台都要设置一个同样的用户，这样要重复设置用户，而且容易造成用户不统一。2. 新建节目的ID不合理。现在是按areanum+audnum这种两个id合成的方式，这种方式的不足：第一，会出现ID不够用的情况，因为现在的个人存储区音频audnum范围是1-100。第二，当以节目ID命名的音频文件存在逻辑错误时，文件无法覆盖、删除，而新建节目的ID又正好与该文件ID相同,这样就无法新建节目。目前我们只能通过插入空记录的方式跳过此ID。比较好的改进办法是用函数生成唯一ID。3. 播出站栏目更新方式有待改进，现在是用循环查询方式更新，这样不断循环会占用一定的网络和服务器资源，如果改成触发更新就好很多。不过，这涉及到系统架构的问题，这种比较低层的程序是牵一发而动全身，一旦确定就很难更改。4. 没有播出预读取。在单轨播出的情况下，播出站播到哪条读哪条，这种方式存在弊端：当读不到要播的音频文件时就会造成播出停顿。可见，这种方式要求网络非常好，不能出现堵塞。改进办法：如果播出站能预先读取到下一条要播的音频文件，播出安全就会更有保障。但是，要想预读取，程序设计就会复杂很多，既要考虑节目是否更改，又要考虑预读取的是不是脏数据。5. 备份程序写的过于简单粗暴。英夫美迪的备份程序是AirBackup, 负责从服务器上拷贝本台的音频文件和数据库到备播站。这个程序只是不断的循环拷贝，完全没有策略，过于浪费带宽和服务器资源。要解决这个问题，有三个值得探讨的方案：第一、做成触发式的，有上单才拷贝。第二、在备份策略上做功夫，设定一定的拷贝时间间隔，不过，这又会导致备播站更新滞后。第三、用数据分发的方式。大家可进一步探讨这个问题，看看有没有折中的办法。参考文献：（1）