JeromeMartinez
commented
1 year ago But the comma-CRLF is indeed in the EBU R98 examples.
But the definition does not include it: "The variable strings should be separated by commas (ASCII 2Chex). Each row should be terminated by CR/LF", my understanding of "separated" is that there are 2 items to separate and the EOL is not an item.
The examples are all with EOL comma, so well, we didn't catch that it is conflicting, and we implemented without EOL comma and some others implemented with EOL comma... And impossible to say who is legitimate.
OK, now we see the spec, the usage, we need to decide about how to handle that. I write a proposal in https://github.com/MediaArea/BWFMetaEdit/issues/251.
Per EBU R98, page 3, example 1&2: https://tech.ebu.ch/docs/r/r098.pdf
CodingHistory examples with single and multiple processes end with ",CRLF" (comma-CRLF) rather than just CRLF.
To add to the confusion, Page 2 of EBU R98 states that each process string ends with CRLF (no mention of the comma one way or the other).
With the EBU CodingHistory Rule enabled or disabled, BWFMetaEdit does not accept comma-CRLF, only CRLF.
On the other hand, FADGI supports both CRLF and comma-CRLF, page 15: https://www.digitizationguidelines.gov/audio-visual/documents/BWF_Embed_Guideline_v3_2021.pdf
FADGI notes on page 15, "Example Sound Directions": "These examples from the Sound Directions project include a comma (“,”) at the end of each line of text but the EOL comma is not included in EBU R98."
But the comma-CRLF is indeed in the EBU R98 examples.
Alas, for 10+ years we've followed the EBU R98 examples with comma-CRLF on thousands of files, but like #251 where the F parameter is not allowed when EBU R98 CodingHistory Rule is disabled, BWFMetaEdit also does not allow comma-CRLF when EBU R98 is disabled.
This will interfere with my workflow if I use BWFMetaEdit on old files and it flags them as non-compliant because of comma-CRLF (resulting in confusion with clients, and extra effort to make them compliant for further use with BWFMetaEdit).
**Might it make sense to allow comma-CRLF when the EBU R98 CodingHistory Rule is disabled to address the ambiguity in EBU R98 and differing examples in FADGI?
Legitimately unclear. Worthy of errata at a minimum but would really appreciate the ability to use comma-CRLF for backward compatibility.