Collection:

Unable to render {include} Couldn't find a page to include called: WAV with Danish Radio broadcasts, ripped audio CD’s, and SB in-house audio digitization

Unable to render {include} Couldn't find a page to include called: mpeg video with Danish TV broadcasts

Issue:

Title	IS45 Audio and Video Recordings have unreliable broadcast time information
Detailed description	The Danish State and University Library (SB) holds large collections of Radio and TV Broadcasts. The duration of the WAV (22.05khz, 16 bit) Danish radio broadcast files in the testbed is approximately 20 minutes to 10.5 hours. This means some recordings cover a number of shows. The mpeg-2 video with Danish TV broadcasts in the testbed dataset are approximately 20 minutes to 17 hours, containing a number of shows. The mpeg-1 video with Danish TV broadcasts in the testbed dataset are approximately 10 minutes to 16 hours, again containing a number of shows. The metadata of the files are Radio or TV Channel ID, start time and end time (part of file names). The SB also has the program listings in a different collection. The recording start and end times are however usually 'a few minutes early' (just before the top of the hour) and 'a few minutes late', e.g. from 2 minutes to 9 am till 3 minutes past 10 am. Also the programs do not always start precisely at the announced time! It would be nice to link the program listings to exact timestamps in the audio and video files, as this would make it possible to cut out single programs automatically when requested. (Note the mpeg-2 transport stream with Danish TV broadcasts are one hour recordings. These also contain metadata on the shows being sent.)
Scalability Challenge	The combined size of the collections in question is 630 TB.
Issue champion	Bolette Jurik (SB)
Other interested parties
Possible Solution approaches	Most of the programs start with a jingle or some sort of recognizable intro. If we can search for this in the audio and video files, we would be able to find the exact start times of different shows.
Context	Details of the institutional context to the Issue. (May be expanded at a later date)
Lessons Learned	Notes on Lessons Learned from tackling this Issue that might be useful to inform the development of Future Additional Best Practices, Task 8 (SCAPE TU.WP.1 Dissemination and Promotion of Best Practices)
Training Needs	Is there a need for providing training for the Solution(s) associated with this Issue? Notes added here will provide guidance to the SCAPE TU.WP.3 Sustainability WP.
Datasets	WAV with Danish Radio broadcasts, ripped audio CD’s, and SB in-house audio digitization Danish TV broadcasts, mpeg videos
Solutions	SO36 Perform scalable search for small sound chunks in large audio archive SO2 xcorrSound QA audio comparison tool

Evaluation

Objectives	Which scape objectives does this issues and a future solution relate to? e.g. scaleability, rubustness, reliability, coverage, preciseness, automation
Success criteria	Describe the success criteria for solving this issue - what are you able to do? - what does the world look like?
Automatic measures	What automated measures would you like the solution to give to evaluate the solution for this specific issue? which measures are important? If possible specify very specific measures and your goal - e.g. * process 50 documents per second * handle 80Gb files without crashing * identify 99.5% of the content correctly
Manual assessment	Apart from automated measures that you would like to get do you foresee any necessary manual assessment to evaluate the solution of this issue? If possible specify measures and your goal - e.g. * Solution installable with basic linux system administration skills * User interface understandable by non developer curators
Actual evaluations	links to acutual evaluations of this Issue/Scenario

Solutions:

Title	SO36 Perform scalable search for small sound chunks in large audio archive
Detailed description	We proposed using the xcorrSound sound_index tool developed in late 2012. A sound index can be made of a number of sound files. Given the program information, the jingle or intro used to mark the start of the program, can then be found in the sound index with an exact timestamp, which can be added to the metadata for the sound files making it possible to cut out single programs automatically when requested. The future of this solution is putting the new tool into a workflow and start testing and evaluation
Solution Champion	Bolette Jurik (SB)
Corresponding Issue(s)	IS45 Audio and Video Recordings have unreliable broadcast time information
myExperiment Link	A link to a corresponding workflow on myExperiment
Tool Registry Link	A link to information about the tool itself. Ideally this should point to an entry in the OPF Tool Registry Click here if you need to create a new Tool Registry entry
Evaluation	Any notes or links on how the solution performed. This will be developed and formalised by the Testbed SP.

Title	SO2 xcorrSound QA audio comparison tool
Detailed description	The xcorrSound QA audio comparison tool compares two sound waves, for instance the audio waves of an original audio file and the audio waves of a migrated file. The tool uses the cross correlation function to find the overlap match. This will give us a match score (between 0 and 1) and also an offset in the second file for the match if the audio has been shifted in the migration (we have examples of this happening). This is not a full solution, but a tool used as part of the workflows in full solutions to a number of issues.
Solution Champion	Bolette Jurik (SB)
Corresponding Issue(s)	IS13 wmv to WAV Migration Results in Out-of-sync Sound and Video IS21 Migration of mp3 to wav IS45 Audio and Video Recordings have unreliable broadcast time information
myExperiment Link	migrationQA SCAPE Web Service Wav File Comparison Workflow
Tool Registry Link	xcorrSound
Evaluation	October-November 2012 Performance efficiency - Capacity / Time behaviour NumberOfObjectsPerHour: Number of mp3 files migrated and QA'ed. The QA performed as part of the issue IS21 Migration of mp3 to wav workflow at the time of the baseline test is FFProbe Property Comparison, JHove2 File Format Validation and XCorrSound migrationQA content comparison. The mp3 files are 118Mb on average, and the two wav files produced as part of the workflow are 1.4Gb on average. Thus a baseline value of 10 objects per hour means that we process 1.18Gb per hour and we produce 28Gb per hour (+ some property and log files). The collection that we are targeting is 20 Tbytes or 175.000 files. With the baseline value of 10 we would be able to process this collection in a little over 2 years. The goal value is set at 1000 so we would be able to process the collection in a week. Evaluation 1 (9th-13th November 2012). Simple parallelisation. Started two parallel workflows using separate jhove2 installations. Both on the same machine. Processed 879+877 = 1756 files in 4 days, 1 hour and 12 minutes. NumberOfObjectsPerHour=18. Functional suitability - Correctness QAFalseDifferentPercent: This is a measure of how many content comparisons result in original and migrated different, even though the two files sound the same to the human ear. The parallel measure QAFalseSimilarPercent is how many content comparisons result in original and migrated similar, even though the two files sound different to the human ear. We have not experienced this - and we do not expect it to happen. We note that this measure is not improved by testbed improvements, but rather by improvements to the XCorrSound migrationQA content comparison tool in the PC.QA work package. The baseline value is 161 in 3190 ~= 5% (test 2nd-16th October 2012). The goal value of 0.1% is set to make manual checking feasible. The collection that we are targeting is 20 Tbytes or 175.000 files. With QAFalseDifferentPercent at 0.5%, we would still need to check 175 2-hour files manually (with the help of the XCorrSound migrationQA tool with the --verbose flag set). Evaluation 1 (5th-9th November 2012). Processed 728 files in 3 days, 21 hours and 17 minutes = 5597 minutes, which is 5597/728 = 7.7 minutes pr. file in average. The number of files which returned Failure (original and migrated different) is 3 in 728 or 0.412 % of the files. It turns out that these "false negatives" may not be false negatives after all, but actually migration errors that were caught. The actual migration was done with ffmpeg version 0.10, and can be re-created using this version, but it does not happen with ffmpeg versions >= 1.0. February 2012 The testbed dataset Danish Radio broadcasts, mp3 which is the basis of issue IS21 Migration of mp3 to wav consists of two hour mp3 files (average file size: 118Mb). When these two hour files are migrated to WAV, we get an average file size around 1.4Gb. In February 2012 the migrationQA workflow did not scale nicely to these two hour sound files, but we have run a test on a file cut to 12Mb (about a tenth of the original size) using dd. The Mp3 to Wav Migrate Validate Compare Workflow (see SO4 Audio mp3 to wav Migration and QA Workflow) used only 34 seconds on the cut file. The migration and the file format validation were successful, but the property comparison reported that the files were not 'close enough'. The reason for this is that cutting the file does not change the header information, so the duration of the original cut file is supposedly 2 hours, 2 minutes and 5.23 seconds, while the duration of the migrated file is 13 minutes and 6.38 seconds. Playing the original cut mp3 using the MPG321 Play mp3 to Wav SCAPE Web Service Workflow (see SO4 Audio mp3 to wav Migration and QA Workflow) used 11.7 seconds. The migrationQA SCAPE Web Service Wav File Comparison Workflow took 1.4 minutes. The result was also negative, but an inspection of the output showed that only the last chunk differed, which probably means that FFmpeg and MPG321 handled the cut off differently.

LSDRT14 Audio and Video Recordings Missing Important Metadata

Collection:

Issue:

Evaluation

Solutions:

October-November 2012

February 2012