struct.error While assembling a wav file with fresh added tags.

[es3n1n]

Hi, the title says it all

Python version: 3.11.4
mutagen version: 1.47.0

from mutagen import File

f = File('dummy.wav')
f.add_tags()
f.save()

dummy.wav - https://files.catbox.moe/63bxyb.wav

Stacktrace:

Traceback (most recent call last):
  File "E:\repos\es3n1n\***\test.py", line 7, in <module>
    f.save()
  File "E:\repos\es3n1n\***\venv\Lib\site-packages\mutagen\_util.py", line 156, in wrapper
    return func(self, h, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "E:\repos\es3n1n\***\venv\Lib\site-packages\mutagen\_file.py", line 132, in save
    return self.tags.save(filething, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "E:\repos\es3n1n\***\venv\Lib\site-packages\mutagen\_util.py", line 185, in wrapper
    return func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "E:\repos\es3n1n\***\venv\Lib\site-packages\mutagen\_util.py", line 156, in wrapper
    return func(self, h, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "E:\repos\es3n1n\***\venv\Lib\site-packages\mutagen\wave.py", line 128, in save
    wave_file.insert_chunk(u'id3')
  File "E:\repos\es3n1n\***\venv\Lib\site-packages\mutagen\_iff.py", line 350, in insert_chunk
    return self.root.insert_chunk(id_, data)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "E:\repos\es3n1n\***\venv\Lib\site-packages\mutagen\_iff.py", line 277, in insert_chunk
    self._update_size(chunk.size)
  File "E:\repos\es3n1n\***\venv\Lib\site-packages\mutagen\_iff.py", line 163, in _update_size
    self.write_size()
  File "E:\repos\es3n1n\***\venv\Lib\site-packages\mutagen\_riff.py", line 41, in write_size
    self._fileobj.write(pack('<I', self.data_size))
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^
struct.error: argument out of range

[phw]

The problem is that the WAVE file reports already wrong sizes. The frame holding the data specifies a size of 4294967295 bytes, which is the max. for an unsigned 32 bit integer.

The data size reported for the entire file is also 4294967295, which doesn't add up already, because with the additional LIST frame and nested frame headers the data size would need to be 4294967374, which could not be saved.

When mutagen tries to add another frame at the end and recalculates the sizes it will end up beyond the 4294967295 limit.

Am I right to assume that the file was specifically created just as dummy test? I'd suggest fixing the file then instead.

[es3n1n]

Am I right to assume that the file was specifically created just as dummy test? I'd suggest fixing the file then instead.

Not really. That file was produced by ffmpeg using the ffmpeg -i original.wav -f wav pipe:1 command.
Funny enough, if ffmpeg doesn't pipe the result to stdout everything works just fine.

Here's the comparasion between the same file re-encoded to a file, and to the stdout.

It does make sense why ffmpeg outputs an uint32 max value to these fields, because this data isn't available at the time when it started re-encoding it, however this is still a bit weird.

I understand now that this file is broken by itself indeed, but how come that wav players could process them? I assume that they're re-calculating these fields by themselves (which should be pretty trivial to do). I understand the problem now and pretty sure I can fix this myself, would you be up to merging my PR with this "fix"?

[phw]

I assume that they're re-calculating these fields by themselves (which should be pretty trivial to do).

I don't think it is trivial. The players probably assume that all the rest of the file is audio data and just play it. I also wouldn't blame a player that stops playing the data after the specified length.

In theory there could be another data frame somewhere at the end, but as the sizes don't match up it wouldn't be found.

The situation is much more complicated when you actually want to modify the file and have to insert data into a file with broken length and positions. It's easy to break the file even more.