BWF bext padding byte

You found a bug or have any issues? Please post them here!
Post Reply
Bo98A
Posts: 86
Joined: 11 Apr 2016 21:29
BWF bext padding byte

Post by Bo98A »

I have an audio file with a "bext" (BWF) chunk that is 603 bytes long + 1 byte padding. I've attached this file. I'm having issues saving a metadata TAG to it.

When ProppFrexx saves the metadata TAG, it seems to overwrite the 603 bytes with 858 bytes but does not remove the padding byte. This leads to the INFO chunk never able to be read because it has a NUL byte at the beginning. Removing this NUL byte allows the metadata to be read.

You should be able to reproduce this issue by trying to save any metadata (e.g. title/artist) via TAG onto an affected file.

(As a side note: ProppFrexx doesn't seem to read the BWF data in this instance? Not too important to me but just something I noticed. I've noticed it with 858 byte bext chunks so it doesn't seem to be due to the padding byte.)
Attachments
Test.wav.zip
(648.84 KiB) Downloaded 447 times
Last edited by Bo98A on 04 Sep 2017 13:10, edited 1 time in total.
User avatar
radio42
Site Admin
Posts: 8295
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: BWF bext padding byte

Post by radio42 »

I'll take a look later today or tomorrow.
User avatar
radio42
Site Admin
Posts: 8295
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: BWF bext padding byte

Post by radio42 »

This BEXT tag is not read, because the Originator is "Logic Pro X".
Logic Pro does save the BEXT tag (esp. the BEXT "Description" field) in its own proprietary format, which is not BWF compliant (e.g. it contains various \0 chars, which would lead to incorrect title and artist info). Thus ProppFrexx ignores BEXT tags from Logic Pro.

The BWF (oncl. the BEXT chunk) is defined e.g. here:
https://tech.ebu.ch/docs/tech/tech3285.pdf

As you can see, the BEXT "Description" field is defined as:
CHAR Description[256]; /* ASCII : «Description of the sound sequence»

The Logic Pro file however contains non-ASCII characters in the description.
I will further investigate, but as of now I assume, that the wave file is not really BWF compliant.
User avatar
radio42
Site Admin
Posts: 8295
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: BWF bext padding byte

Post by radio42 »

The save issue with the wave file is, that the length information is NOT correct for the BEXT chunk.

As you already mentioned, the current BEXT chunk length is set to 603!
However, all chunks needs to be word (16-bit) aligned AND the chunk size MUST include the padding byte.
Thus, the correct length of the BEXT chunk MUST be 604 instead of 603.

When adjusting the BEXT chunk size to 604, the file can again be saved correctly!

Thus: Your wave file is simply not correctly created in the first place.
Please contact the vendor of the application which generates the incorrect file and report a bug with them.

I am afraid, that I can currently not do much about this issue, as the file is already corrupt.
Bo98A
Posts: 86
Joined: 11 Apr 2016 21:29
Re: BWF bext padding byte

Post by Bo98A »

radio42 wrote: 25 Aug 2017 10:34As you already mentioned, the current BEXT chunk length is set to 603!
However, all chunks needs to be word (16-bit) aligned AND the chunk size MUST include the padding byte.
Thus, the correct length of the BEXT chunk MUST be 604 instead of 603.
I was under the impression that the chunk size should not include the padding byte as per http://www-mmsp.ece.mcgill.ca/Documents ... iffmci.pdf
ckSize - A 32-bit unsigned value identifying the size of ckData. This size value does not include the size of the ckID or ckSize fields or the pad byte at the end of ckData.
User avatar
radio42
Site Admin
Posts: 8295
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: BWF bext padding byte

Post by radio42 »

You are right. It must NOT include the padding byte.
I'll look in detail when I am back from holiday.
Probably the incorrect BEXT Description field coding of Logic causes the issue.
User avatar
radio42
Site Admin
Posts: 8295
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: BWF bext padding byte

Post by radio42 »

I have looked at it in a bit more detail.
The issue seems a bit more complex...
The minimum BEXT size is 602 byte. It might be followed by a "Coding History", which is a series of string, which must each be terminated by \r\n.
Your file contains a "Coding History", which seems to only consist of a single \0 byte - thus you got a length of 603.
However, I am not sure, if such a coding history is valid, as it is actually a null string and not terminated by \r\n.
If there is no coding history it should normally be omitted completely.

So I need to look at it next week, if I can find a workaround... still it seems not fully correct what was written originally.
Bo98A
Posts: 86
Joined: 11 Apr 2016 21:29
Re: BWF bext padding byte

Post by Bo98A »

radio42 wrote: 26 Aug 2017 21:02 However, I am not sure, if such a coding history is valid, as it is actually a null string and not terminated by \r\n.
If there is no coding history it should normally be omitted completely.
I would agree this would've been the ideal approach, but NUL bytes in the coding history doesn't appear to be invalid - in fact ProppFrexx fills it with 256 NUL bytes.

That said, I've modified the file to remove any doubt. I've changed the coding history to "A=PCM,F=44100,W=24,M=stereo,T=testing\r\n" and cleaned up the Description section. The exact same issue is happening (the bext length is now 641 bytes + 1 byte padding), and I've attached the new file to this post.
Attachments
Test 2.wav.zip
(648.77 KiB) Downloaded 418 times
Bo98A
Posts: 86
Joined: 11 Apr 2016 21:29
Re: BWF bext padding byte

Post by Bo98A »

Thank you, it is working now!
User avatar
radio42
Site Admin
Posts: 8295
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: BWF bext padding byte

Post by radio42 »

I just uploaded a new v4.0.3.65-update - which implements that workaround and fixes the BEXT padding issue!

Post Reply