Legacy Media, Migration, Mechanical Captioning, & Migraines
[Text below drafted, but not published, early summer 2016, as I was trying, solo, to make a decision about whether or not to migrate Blackbird’s legacy media files to Kaltura, a video system adopted by VCU. Ultimately, I decide not to use that platform for the legacy files and in the first pass at mending he archive last summer, I have converted much of the archived media into mp3 and mp4 files that are saved in the structure of the journal on the web server, rather than being hosted, as before, on a media server. —Michael Keller]
In the spring of 2016, VCU announced it would be taking down their “video server” on June 30, 2016. This server contained media files for Blackbird, vol 1-8 (legacy real media) and vol 9-12 (flash server). There were no plans to automatically migrate any of the legacy video server files to Kaltura, the new system; that responsibility rested with the individual faculty member, unit, or organization. This, based on the assumption that anything on the old video server was likely outdated, poor quality, or otherwise not of interest to migrate.
At the time of the announcement, Blackbird was working hard on the spring issue, and the magazine was down two expert staff members, having recently lost a faculty-line online editor and a graduate student lead developer. With this staff loss, I could not stop to investigate all the shutdown was going to mean for us come summer, though I did email local Kaltura support queries about the possibility of a batch move of data to Kaltura, but my question was lost in the shuffle.
By the time we published the spring issue in May of 2016, and I was able to meet face-to-face with a very amiable support staff member about Kaltura, the problem was this: almost every question I asked in the meeting had not been raised by anyone before in the planning and execution of the server shutdown.
Blackbird‘s needs and problems were (as usual) unique to the journal and its history. The idea that we were trying to preserve an active fifteen year archive of material came as a surprise to IT staff members.
Although there were a number of issues, my chief concerns, after some self-study of Kaltura, were as follows:
1) is batch migration and conversion of 502 real media files from v1-v8 possible? What about flash server materials from vols v9-v12?
2) can the journal opt out of auto-captioning by Kaltura on upload since we cannot, of course, publish unedited captions.
At the time of my meeting with support, there was no batch import solution, which would mean that I would have to manually upload files one at a time to Kaltura, where they would be auto-captioned by default (at that time) in our institutional setup.
It turned out that
1) no batch option for file conversion was available
2) there was no option to opt out of caption and no way to hide the caption toggle in the player; the only option was to manually and individually delete captioning after the fact.
In addition, each manually converted file would have to be embedded on the page in a Kaltura player, which was optimized for video only; there is not really an “audio playbar.” Attempts to make one by reducing (and hiding) the video playback space, as we do with JWplayer, were stymied by the design of the playback controls.
On examining this possible solution, I realized the high number of times each of the v1-v8 502 files would have to be handled. 1) dowload from video server 2) rename* 3)import to Kaltura 4) tag (multiple tags, including volume and issue, genre, and contributor name) and wait for enforced, but unusable, captioning to complete 5) export captions for future reattachment and editing 6) rename exported caption files to match the name of the associated media file 7) copy embed playback code and file path. 8) place embed code on web page while dealing with any formatting/layout changes in legacy pages 9) publish to test server and check playback 10. have proofers/copyeditors do a thorough review of any formatting and/or textual changes and noting any changes to the document using code comments 11) republish to live server
So without taking into account other page issues (such as the cleanup of old code and deletion of local real media files containing paths that redirected to the video server (the way RealMedia worked), you have 11 actions (really more given the tagging, etc.) x 502 for over 5522 actions. That seemed a little much, especially if Kaltura is not an archival solution in and of itself, but a delivery system that would, itself, be replaced in some future update cycle.
A further note on captioning
Unedited captions were unpublishable. That’s a given. The examples below come from my first two tests of some departmental legacy audio.
In a Fizgerald lecture: “For his part Fitzgerald is going on the rag and often simply meant that in fact he would sway a awful fart liquor but would continue to consume vast quantities of beer and wine . . .”
In a lecture on the Waste Land, the poem title is auto captioned as “The Worst Run” and “The Waist Line.”
But knowing that we would, at a later date, want to be able to edit, and make public, captions, I hoped we could, in the embedded player, toggle off the choice of captions as publishers; that is, we wanted to hide access to the captions until they were edited. This was not an option, so my only choice, after waiting for up uploaded file to be processed through auto-captioning, would then be to delete the captioning.
Well, I thought, if the captions will already have been processed, we should probably plan to save the caption file down until such time as we can reattach it and edit.
Turns out that when you export a caption file in Kaltura, it does not name it in alignment with the source file; in other words levine.rm does not save out as levine.DXRP. It saves out as english.DXRP, as in “English language,” as does the next, and the next. so you end up with a list of exported files that looks like
english.DXRP
english1.DXRP
english2.DXRP
english3.DXRP
english4.DXRP
etc.
So if I wanted to retain the captions for further edits and reattachment, I would also have to stop to manually, and very carefully, save the exported caption file to match the name to its associated media file.
* [On renaming] Because the legacy source files came from a file and folder system, the file path, not necessarily the file name, identified the issue of the journal and the author of the piece. For instance, I only know that “interview.rm” below is a conversation with Phil Levine and in Blackbird v1n1 because of the containing folders.
video.vcu.edu/blackbird/v1n1/levine_p/interview.rm
Whether we has used Kaltura or not, it became clear that each file, upon conversion to a new format, would have to decide on a model for a more self-descriptive filename. Below is what I adopted on the fly, though I wonder/worry that we should have written out “blackbird” for “bb.”
bb-vxnx-contributorname-firstinitial-keyword-mp3
e.g.
bb-v1n1-donovan-g-interview.mp3
Categories Archive maintenance, Captioning, Kaltura, Media conversion