[FFmpeg-trac] #10229(undetermined:new): Wrong data size for WAV (RIFF) format

[FFmpeg]

#10229: Wrong data size for WAV (RIFF) format
-------------------------------------+-------------------------------------
             Reporter:  polochon     |                    Owner:  (none)
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:
                                     |  undetermined
              Version:  unspecified  |               Resolution:
             Keywords:  pcm_u8 RIFF  |               Blocked By:
  WAV                                |
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Comment (by polochon):

 It's pretty hard to discuss, you don't answer to all my points.... So this
 is my last question.

 Based on the principe that there is an odd samples number (I forget
 mediainfo output voluntarely), and regarding the official specifications:
 -
 https://www.mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/Docs/riffmci.pdf
 - https://learn.microsoft.com/en-us/windows/win32/directshow/avi-riff-
 file-reference#riff-file-format

 I've extacted the very important sentence:
 > ckSize gives the size of the valid data in the chunk; it does not
 include the padding, the size of ckID, or the size of ckSize.

 If we look again in Pwork.vaw:
 at address 0x28: 0x753=1875 samples
 And the end pf the file:

 {{{
 00000770  80 81 81 80 80 80 80 80  80 80 80 80 80 80 80 00
 |................|
 }}}


 The last bythe is the padding byte, OK! So whatever the real samples
 number, this is coherent with the specification and a good point.

 However in this case the ckSize at address 0x04 (0x0778) include this
 padding byte despite specification seems assume it shouldn't be the
 case... It seems ffmpeg at this point consider that the last byte is a
 data like another and count it in the global size.

 What is your point of view on this point? Is this behavior specific to
 ffmpeg or all software are aligned?
 Thanks in advance, lot of kids are stuck whith no sounds in their robots
 at this moment :/
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/10229#comment:8>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker