A very hidden bug in DVdate

I released this morning my DVdate software version 8.0.6, after fixing a bug well hidden. It happened during the DV video conversion from PAL to NTSC or vice versa. So far DVdate was producing the requested file in NTSC or Pal and it had the required qualities of such a file when it was processed in most video tools.

Nevertheless, when I wanted to decode this file with ffdshow Video Decoder instead of using the good old DV Video Decoder from Microsoft, then it gave no more image, but only the sound.

I discovered that DVdate forgot to change a byte in the frames of the resulting file. It’s a byte that is used by some decoders to recognize the standard file: it is $ 3F for NTSC and $ BF for Pal. So it’s actually only a single bit that is badly marked, but that was enough to cause difficulty reading with ffdshow, and other decoders like LAV Video Decoder, which are therefore more demanding on compliance with the standard that does Microsoft with its DV Video decoder. This is fixed in the version published this morning.

I remain surprised by the fact that for years that this command exists in DVdate nobody has spoken to me about it. This is probably because those who have files processed with a version of DVdate affected by this bug, could use them almost normal way, as was my case until yesterday.

However, if some users with large amounts of files converted to Pal or NTSC by DVdate, need to fix them, and they can not convert back from the original files, then I will eventually consider adding a fix command in the next version of DVdate. But as the utility of this command would be very focused on a very particular problem and probably uncommon, I would rather avoid cluttering DVdate with an additional command that most users will not use. I hope that the users concerned will then settle with my apologies.