compared with
Current by Niels Bjarke Reimer
on Jul 16, 2013 07:18.

This line was removed.
This word was removed. This word was added.
This line was added.

Changes (1)

View Page History
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.
h5. February 2012
The testbed dataset [SP:mp3 (128kbit) with Danish Radio broadcasts, mp3] which is the basis of issue [SP: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 [SP: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 [SP: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. \\ |