Possible CR LF bug in BEXT

[Pier House Studios]

to whom etc,

I have found that FITS reports (correctly) the absence of the required CR LF termination of the coding history section of the BEXT chunk but after using FADGI to rewrite the file it still seems to indicate a problem. FADGI inserts the required 0D 0A.

The second point concerns the calling of the Droid application, I have two systems running FITS, a small notepad (OS = Win7 starter) and an HP Z820 running W7 64. FITS calls Droid on the notepad but not the Z820 using identical files.

As before I'm happy to supply copies of files.

Just a quick note - I am delighted to have found the application!

With kind regards,

Peter Haigh

[David Birtwell]

Peter:

Please send us a link, or the file in question, that way we could quickly analyze what you are seeing and tell if it is indeed a problem with FITS.

As for the DROID issue, which version of Java are you running? Right now, FITS and the version of DROID we are currently using in FITS will not run on Java 8.

If Java 8 is being used on the Z820, then DROID will just log an error message (quite subtly) that it does not handle Java 8.

NOTE: A future release of FITS (sometime in the near future) will support the latest version of DROID on Java 8.

Thanks,

Dave Birtwell

[Pier House Studios]

Dear Dave,

You were correct about the Java versions, I'm running 1.8 on the Z820 and, confusingly, the latest version of DROID which is fine.
I'll send the file in a day or so when I get a moment.

Thanks for your reply.

With kind regards,

Peter Haigh

[Pier House Studios]

Dear Dave,

I'm sending you two wav files, the one with "fixed" as part if its name has been corrected by FADGI.

I also attach two HTML files which show the relevant part of the WAVs as hex dumps, you'll see the insertion of the CR/LF or 0xOD 0xOA at the end of the coding history part of the bext chunk.
FADGI reports the unfixed file as incorrect when its rules are set accordingly and is happy with the fixed file.

I wanted to be certain that I wasn't muddying the waters by sending non-compliant BWFs but I think these pass muster. I'll be interested to hear your views.

I ran the FITS test on both Java 1.7 and 1.8 with identical results.

With kind regards,

Peter

 

On Monday, 28 September 2015 14:24:34 UTC+1, David Birtwell wrote:

[David Birtwell]

Peter:

I'll send these to our preservation expert and have hime review the files. I'll let you know what we see as soon as I hear from him.

Thanks,

Dave B.

--
You received this message because you are subscribed to a topic in the Google Groups "fits-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fits-users/8HXr-AUFLQE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fits-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Ackerman]

Hello Peter,

Dave passed on your question about the CR/LF terminator not being recognized. I looked at your hex dump for the fixed file and I see that the last CR/LF of your coding history is followed by 2 null bytes which are included in the chunk size count. I'm not sure how you made this file but this looks to be an error in the writing of the file. AFAIK, the coding history terminates the BEXT chunk and there should be nothing between it and the next RIFF chunk, unless a pad byte is required to word align the file (i.e. the BEXT chunk's size % 2 != 0). In that case the single pad byte would be there but not reported in the chunk size as it is not actual data to be consumed by the app reading the file. So, I'm not sure why there are 2 null bytes between the 0A and the 64  but I think this is the problem. -> 0D 0A 00 00 64 61 74 61

Very best,

David

[Pier House Studios]

Dear David,

Thanks for your informative reply.

I'm unable to respond properly at the moment because of work pressures and I will need to go back to the EBU BWF docs to see what is happening.
I can say that this evening I encountered the same CR/LF report again with a BWF file from the latest version of Avid MC (BEXT at end of file) and also with a ProTools file which admittedly had to have the BEXT chunk added by FADGI.

I'll let you have the information in the next few days.

Kind Regards,

Peter

Peter

[Pier House Studios]

Dear David,

please have a look at this sample which fails the CR/LF test in fits.
It is a 10 second tone created in ProTools.
I used FADGI to insert the coding history which has a text string at the end ending in CR/LF.
The lengths of the various parts of the BEXT look OK to me and I attach a copy of the FADGI manual giving the lengths of the sections.
It's a BEXT ver 0 file. The coding history is only 40 bytes long but I cannot find anything to suggest a minimum length.
The coding string looks OK according to the EBU 3285 and the r098 addendum.

There's also a hex printout of the file up to the start of the data chunk.

I haven't had time to test this with higher versions of the Bext but see what you think . . .

3 files attached, WAV and pdf and html.

Just one final thought, it would be good if you could send me a short file that works so I can test my system.
I don't think I have got anything with a coding history to work in FITS and that makes me suspicious about my set up.

Kind Regards,

Peter