Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Bug: invalid Wave: truncated #41
I have some file which display this in the console:
The metadata displays just fine in other application I use, like REAPER.
If other apps can display this right, maybe BWFMetaEdit is a bit too strict ?
Thanks for your support !
Letting you know that your wav file is malformed isn't simply being strict but being informative. Although other applications don't have these warnings in scope, this type of validation issue is certainly in scope of BWF MetaEdit. Your wav file likely has a size declaration in its header that is larger than the actual file, so you file is likely a partial or truncated copy of another file and there is audio at the end that is missing.
@dericed Oh yes it is informative, but not having, the possibility to see/process information, is restrictive (considering that other apps can show them). It is not just a informative warning, I can't for eg dump the avaible metadata.
Apart from re-render the file, is there anyway this could be fixed ?
With other tools you thought that all is OK, this is not the case. It is already a good thing to have a messenger saying something went wrong, don't you think? Then you can use other tools for digging in the file.
Which "metadata" do you need? the exact position and value of the issue? True, it is not in BWF MetaEdit because it was not expected in the design, when we started the project. It could be implemented if there is enough need about it. If you look for a byte per byte dump of the file right now, you can check MediaConch, open the file for checking then click on "MediaTrace" button for the file. You still need some knowledge about WAV structure as the exact issue is not showed (it is only a dump).
It is not possible to invent missing data. No need to re-render the file, finding a good (before the truncation) copy of the file should be enough, I personally expect that the rendering tool correctly stored the file. If you lost this file, the only solution is to re-render the file, as the data is lost.
I thought there might be a tool which could define new end for the file (at the last readable data ) and update metadata accordingly.
Anyway, thanks for your infos and expertise.
For sure having good file right from the start would be the better way but sometimes there us just no way to get back.
Note that I use BWFMediaEdit CLI version mostly so other non CLI version might not work in my case.
This is from a broken file:
As you can see there is some metadata infos there. This is pretty nice, but doesn't solve the data injection problem (which was what I wanted to do in a first place). For MediaConch, the file appears to be valid. So it is just BWFMetaEdit who can't process it (extracting or injecting metadata).
Just an extra post for clarification. My case was the following:
But it breaks.
I tried with other BWF injection solution like wavefile and this works. It sure didn't reinvent the missing data (if there is missing data, maybe it is just wrong metadata infos), but it made BWFMetaData readable and writable again in BWFMetaEdit.
So, a way to fix metadata sounds possible, having that with BWFMetaEdit CLI version would be nice !
Usually (important: not the case here, it is just an explanation about the idea behind the current way it is working), a truncated file is due to bad transfer, data is missing.
You provided a MediaInfo XML, not a MediaTrace one.
Checking your file, issue is not the one @dericed thought about, the message was misleading (reason MediaConch ignored it, as it shows an issue only if the file is shorter than expected. Note that MediaConch does not have a WAV file conformance checker, the message "valid" should be "not applicable", something we need to fix in MediaConch).
You can see that there is a problem: WAVE chunk says that end is at 0x5B3A28 (8 bytes of start of header + 0x005B3A20), _PMX chunck says that end is at 0x5B3A30 (offset 0x5B2CE6 + size of 0xE4A), 8 bytes later --> This is incoherent, the file is buggy.
In that case, currently BWF MetaEdit prefers to not edit the file, as there is a risk that something went wrong somewhere (this is not a file transfer issue, as the WAVE chunk header is coherent with file size), and it is more development work to edit other fields (e.g. bext chunk) while keeping such bug during rewrite (in order not to hide the issue). @dericed, a quick and dirty fix could be to ignore such bug in a file and "correct" it silently (1 line patch), but I am personally not in favor of such solution because I don't like to hide the issue in the file.
Checking the file, the XMP content is with spaces at the end, so low risk that some data was lost (just missing 8 spaces?), so we could add a check of such buggy file and fix it, this is just not yet implemented.
In other words, your file is a scenario of non conforming file we chose to avoid in our development, as it was not requested by the sponsor. Support of such buggy file (with different scenarios in order to be sure that BWF MetaEdit does what the user expects, whatever is the user expectation) could be added on request.
summary: I see 2 issues:
If it fits your needs, that's fine. BWF MetaEdit is just (currently) not adapted to your need of edition of such buggy file, we may have just have different priorities (my priority is to not miss a bug in a file, and to not hide it silently during rewrite, as wavefile does).