What is strange, is that your .wav screenshot shows ‘multiple values’ as bitrate. I’ve never seen that for .wav, and was expecting something like that for a VBR MP3 - which in your other screenshot shows 192 kbps. I would ask, what type of .wav is this?
I don’t think it’s VBR PG. VBR would probably be even further off. I think the long file is probably 128 CBR, and still time is misreported by Windows Explorer even in Windows 10. And probably by Mac Finder. Testing, I also get incorrect times in Explorer and Mac Finder with Wavelab FR 128 CBR with long files. The MP3 is reported 5 seconds shorter than the WAV for a 36 minute file.
It goes back to this:
It needs to be corrected in Wavelab (just like the VBR problem with all Wavelab VBR MP3), because it doesn’t happen with MP3s made by other programs like iTunes.
The file time appears correct when opened normally in VLC. The file time appears incorrect when added to a VLC Playlist (until the file is played), and that is not as it should be.
But all of this is beside the point, because MP3s are for clients and they should appear and play correctly no matter where the client views or plays them. ALL other program’s MP3 times appear correct in Windows Explorer and Mac Finder, as they should. And Wavelab MP3s should too, so this should be fixed as it is in other programs. The long file CBR timing problem is with Wavelab Fraunhofer CBR. Doesn’t seem to happen with Wavelab LAME CBR here.
The worse problem is the VBR problems, because Wavelab is the ONLY program making VBR MP3 anymore that doesn’t use VBR headers, so times are misreported in many situations, and player playhead behavior is adversely affected, which makes absolutely no sense coming out of a mastering program where clients are sent MP3 files.