The document "Multimedia Programming Interface and Data Specifications
1.0" issued as a joint design by IBM Corporation and Microsoft
Corporation, August 1991
(http://thewelltemperedcomputer.com/Lib/WavSpec.txt) states "When
storing multiline strings, separate lines with a carriage return/line
feed pair (ASCII 13/ASCII 10 pair)". As an extension of the RIFF Tagged
File Format it follows that the bwf bext chunk should follow the same form.
That said, it is my experience that multiline data in RIFF chunks causes
more problems than is solves, particularly in respect to line endings.
Line endings differ between Windows and Linux and they can also cause
problems when extracting data to csv. There have also been problems with
some data extraction tools
(http://avcodec.org/pipermail/ffmpeg-trac/2011-May/000860.html).
Whilst it is possible set filters to adjust line endings on extraction,
IMO it is preferable to use the aXML
(http://tech.ebu.ch/docs/tech/tech3285s5.pdf) chunk for data which does
not fit easily onto one line.
On 25/01/2012 10:51, Gregorio Garcia Karman wrote:
> Dear list,
>
> ...thanks for the useful and hilarious responses!
>
> Here a more technical question regarding bwfmetaedit. I am trying to automate the writing of metadata to a set preservation master files using FADGI BWF metaedit's command line interface. This works well, but I am having difficulties writing a multiline content to the<bext> field<CodingHistory>. I am trying to do something like this:
>
>
> but the<br /> does not get interpreted correctly. Until now I have tried a number of alternatives from OSX's bash with no sucess. Suggestions?
>
>
> Gregorio Garcia Karman
> +44 (0) 7532 127 645
> [log in to unmask]
--
Mike Hirst
Managing Director
DAS-360°
16 Ocean View
Whitley Bay
Tyne & Wear
NE26 1AL
tel: 0191 289 3186
email: [log in to unmask]
web: http://www.das360.net
|