• 沒有找到結果。

模組儲存與資料庫管理

在文檔中 立 政 治 大 學 (頁 28-36)

此節主要在探討模組製作完成後如何分類建檔儲存,以及資料庫的分類與管 理,業者所掌握的關鍵因素。

一、模組的建檔

表 4-4:各類模組建檔儲存之作法

模組種類 建檔儲存之作法

台歌台呼 1.台歌台呼建檔仿照資訊類。

廣告 2.廣告建檔仿照資訊類。

音樂 1.由節目部的主管或音樂總監主導。

2.依電台定位將合適的音樂轉檔入庫,接著區分類別、設定編號 ID、歌曲和 專輯名稱、歌手、性別、詞曲作者、年代、曲風、情緒、力度、節奏、速度、

織度。

3.更精細的作法是再將歌曲的前奏、副歌、尾奏的時間長度作標示。

新聞 1.做分類、標記與提示,包括類別、新舊、重要性、時效性、使用次數、使 用紀錄等。

2.播出後儲存須標明作者、關鍵字、日期。

公共事務 與資訊

1.使用頻率最高的類目就是編號、名稱、類別、關鍵字、時間長度。

2.若模組單元具有既定的生命周期,類目應包含有效期限。

在儲存模組時,節目產製者一致認同建檔的重要性。妥善建檔後續才能方便運 用自動播出系統,按照條件設定編排出節目單。「RCS 是說未來的系統功能是你只要告 訴他你要的感覺,看有幾個條件就給它,它就依據這種描述性的條件去找你需要的東西,但前提

是要把這些條件先建立好。如果是說在乎節目調性的話,資料庫的建置就很重要,後面的工程就

會容易點。(B)」對業者來說,若資料庫建置時各模組儲存建檔不佳,將影響後續節 目的排播呈現。而各種類模組單元的建檔都必須有統一規劃的做法,如 F:「比方

74

歌手建檔,kinki kids 可以建近畿小子,建檔的方式不一樣,就很難搜尋使用,在國外都是由一兩

個人來負責這件事情,可以避免你建的和我建的都不同。」另外,類目的設定也得注意「可 以發展很多類目,類目要很清楚,如果單元很多比方資料庫有幾萬筆時才好找。(A)」。所有受 訪者表示,進入資料庫的模組,只要都做好分類定義,搜尋的時候輸入名稱、編 號等,比如 F 敘述「在介面上使用 S (代表 search)功能…」,就能快速找到符合條件的模 組,故妥善建檔後搜尋便不成問題。

參照表 4-4,音樂的部分根據所有受訪者的說法,在入庫時每一首歌曲都須分 類定義,「可能它的年代阿,演唱人阿,節奏阿,然後一些特殊節日阿,一些特殊的得獎記錄 等等…。(E)」如 F:「當我收進來音樂網資料庫,我為何花那麼多時間整理,就是希望今天放 進資料庫的都是有用的。當以後需要使用的時候…這些東西是有價值的東西,不是一堆亂七八糟

的資料…。」C:「其實一開始建檔我們把它建好,然後之後很多編排,就弄出來非常方便…蒐 尋也更簡單…例如我打「王力宏」,就會秀出全部相關的檔案。」「可以排序阿,只要你建檔的

檔名建好就很 easy(B)」綜合各電台節目部相關文件與節目產製人員的解釋,發現從音 樂蒐集到分類入庫,主要由節目部的主管或音樂總監主導,先依照電台定位將 CD 中合適的音樂轉檔入庫,接著區分類別、設定編號 ID、歌曲和專輯名稱、歌手、

性別、詞曲作者、年代、曲風、 情緒、力度、節奏、速度、織度,更仔細一點的 作法還需要將歌曲的前奏、副歌、尾奏的時間長度作標示。

而針對新聞類,全部的受訪者也指出新聞須要分類定義。D 舉例新聞會做好 分類、標記與提示,包括類別、新舊、重要性、時效性、使用次數、使用紀錄等。

如:「每個稿子的重要性…甚至於哪些稿子它有時效性需要去注意或是哪些稿子需要去跟別的東 西做搭配。」如此一來在進行挑搞與新聞編輯時,才能有效率:「比方陳水扁的案子,

就可以方便找出來,這就是審稿的時候,要去做分類分等、提示。」D 進一步陳述當新聞播 出後,原始的內容包含記者的文稿,記者的聲音和受訪者的聲音、照片,會整合 儲存在歷史資料庫中,若有需要使用,可以用作者、關鍵字或日期來搜尋。

75

統整受訪者的說法,發現台歌台呼、廣告建檔的原則、方式和資訊單元大致

相同:「台歌台呼建檔也像是在建資訊單元…都是屬於RCS裡的Linker部分…(F)」。B也說明:

「廣告歸檔跟資訊單元類似,有流水編號、單元名稱、內容名稱,內容如果是for客戶的,甚至前

面會有單位、什麼案子的、RCS的卡號等。因為除了文稿,你還要抓到音源嘛,但我們會用盡量

很精簡的方式來處理。」

透過文件分析,發現 A 所任職的電台,發展了一套完整的資訊單元檢索類目,

有單元類別、名稱、製作人、集別、本集名稱、關鍵字、功能、呈現方式、適合 對象(性別、年齡、教育程度、職業)、演出人員、呈現氣氛、適合收聽場所、適 合季節。而有 8 成的受訪者表示資訊單元在建檔時,使用頻率最高的類目就是編 號、名稱、類別、關鍵字、時間長度。再者,若模組單元是有既定之生命周期(像 是某些資訊單元或廣告),使用一段時間後必須下檔,那麼類目就應包含有效期 限,「有些東西是有時效性的,要事先註記,不要讓排播的人誤用。(C)」F 並解釋:「其實電 腦裡面欄位有 start date、 killed date…可以決定開始播出的日期幾月幾號,時效到幾月幾號就刪

掉…。」C 考慮之後增設單元內容簡介的欄位,「也許以後我們可以多一點介紹,要使用 的人可以多一點了解。」但類目欄位並不是訂的越細越好,是必須衡量電台的需求,

考量分類的目的,未來將如何使用,再來決定適合的欄位類目。

參照文件,目前在業界所使用的自動播出系統中,有內建各種類目欄位,比 如音樂的部分除了註記歌名、演唱者、作詞曲者、發行公司、類別,也會有各種 參數可以設定。另外,而自動播出系統的欄位類目除了提供音樂分類定義以外,

F表示:「RCS開發的欄位、定義分類除了給音樂,如果我要文稿類的也有一些基本欄位的設計,

比方song notes、artist notes,然後那些notes除了可輸入文字也可以做圖檔。」「…比如說有些電台

有口播的單元什麼的, 那其實有那個欄位notes,都可以把你要口播的文稿直接打在那個裡面。

當你今天要播報哪一個活動時候,看到那個linker要播報活動,就可以把notes點開來看。」

雖然自動播出系統,其資料庫結構能夠提供各種欄位註記,但B認為:「畢竟

76

RCS是美國公司開發的,不一定符合我們台灣的需求。」所以目前正在開發新的軟體,讓 除了音樂以外的各種模組單元能夠分門別類管理,「一有新的資料就建入,日子久了就 成了一個完整的資料庫。(B)」E則使用Excel做輔助,為資料編號整理:「用EXCEL電子 檔做表格,就會有幾種節目單元、哪些名字,就會分類。例如節慶有哪幾種,滿方便的。」

77

B 表示在電台內部網域有規畫一些公共資料夾、群組資料夾、備份資料夾等 不同的分類模式,讓原始的音源檔案、後製當中的音源檔案跟成品的音源檔案分 別在不同的地方做管理。當模組單元階段性任務已經達成了,在短期內不會再使 用的話,就會轉到備份資料夾內。歸納所有節目產製者的說法,發現資料庫中儲 存的是等待排播的完整單元,但模組單元製作過程中的各種半成品,有 9 成受訪 者也會另外保存。F 解釋:「有要排檔播出的才會灌進 RCS 的 Linker,一些單元備份、半成 品…等是在 share 出來的工作站資料夾裡面。」

這些半成品包括音源與乾話,「我們請歌手來錄音的OS檔案會保存,這些音檔可能會 留著,錄好的公司都會做存檔(F)」「有的時候我們除了錄專訪外,也會錄下歌手幫電台promote

的一句話。這些內容我們都會留…基本上音源保存下來,怎麼播怎麼用那是另外一回事了。(B)」

而除了音源、OS以外,有近9成的受訪者表示單元的文稿也會儲存。如E之陳述:

「就是那個單元都要寫稿,然後這些稿件都要入庫…。」對節目產製者而言,所有製播的 模組單元,除了即時發揮形式的講播或訪談內容沒有文字稿以外,其他內容都會 有文字稿,撰寫完一定會儲存。針對儲存各種半成品的原因,F解釋:「如果有存下 當初製作時的工作頁面,在多軌的畫面裡把東西都存好,要修改時只要叫出來改其中的部份,就

可以了,非常快速。」B認為:「這對公司未來的資產保存比較容易。」A則指出:「我們會 考慮以後要在其他通道上使用…」「可能未來加工貼在網路上,或者是未來數位廣播有可能可以

用。(E)」可見只要半成品有妥善儲存,小單元若需要修改則不必全部重作,浪費時 間和人力,且這些半成品都是公司資產,未來可能能夠再次加工使用。

所有受訪者認為,因為模組是電台的資產,在管理上除了必須劃分使用權限,

定期淘汰及更新也相當重要。F 舉例模組的更新方式:「比方這周要播張惠妹的大卡 司,先放在分享資料夾,要排播我就改 Linker 裡面的 title 跟裡面的音源,我每個禮拜就改 title、

人名、音源,ID 卡號都是事先就開好了,把舊的蓋過去就可以了,ID 我不用再重新指定。」F 認為目前這樣的作法可以讓資料庫處於隨時更新的狀態。另外,E 說明若有些歌 曲存入資料庫時品質不好,或是資訊單元有問題,也會立即修正或是淘汰。「如果

78

有些模組已經不合時宜,我們也不會把它繼續留在資料庫占空間,基本上資料庫我們每半年至少

會更新一次。(E)」B 也表示資料庫中的資訊內容,或是音樂素材,都會固定去檢討 及更新。「即便是原來的單元不做更新,過段時間我們也會重新考慮它的包裝模式或者是片頭的

會更新一次。(E)」B 也表示資料庫中的資訊內容,或是音樂素材,都會固定去檢討 及更新。「即便是原來的單元不做更新,過段時間我們也會重新考慮它的包裝模式或者是片頭的

在文檔中 立 政 治 大 學 (頁 28-36)

相關文件