IsMusic() PNG problem

[Flinx]

I received an MP3 file that IsMusic() incorrectly reports as not music. The file is also reported as unknown/unsupported format by OpenMusic().
Since it is played by other players, I looked for the cause, and it is the embedded PNG cover image. If I transfer it (with Mp3Tag) to another MP3 file, the same error occurs there, regardless of whether it is saved as ID3v2.3 or ID3v2.4.
If I open the image with IrfanView and save it again as PNG (compressed or uncompressed) and then use it, the error is gone.
Here is the image (1 MB, Pw is the title of this post).

And I noticed another questionable behavior of IsMusic(): After the call and negative result, the tested file remains open and cannot be changed by other programs until the Hollywood script has been terminated.

[Juan Carlos]

The problem with the files open with a Hollywood program is with all files, not only with the music, also if the file is video, graphic, even is impossible delete the open file.

[Flinx]

The problem with the files open with a Hollywood program is with all files, not only with the music, also if the file is video, graphic, even is impossible delete the open file.

That's normal and you have it in all programming languages. And of course IsMusic() must open the file to check it, but then it should be closed regardless of the result.

[airsoftsoftwair]

I received an MP3 file that IsMusic() incorrectly reports as not music. The file is also reported as unknown/unsupported format by OpenMusic().
Since it is played by other players, I looked for the cause, and it is the embedded PNG cover image. If I transfer it (with Mp3Tag) to another MP3 file, the same error occurs there, regardless of whether it is saved as ID3v2.3 or ID3v2.4.
If I open the image with IrfanView and save it again as PNG (compressed or uncompressed) and then use it, the error is gone.
Here is the image (1 MB, Pw is the title of this post).

Hard to tell who is the culprit here. MP3 runs through a lot of different backends. Which operating system are you on? Are you using the AVCodec plugin or an OS-native streaming backend?

And I noticed another questionable behavior of IsMusic(): After the call and negative result, the tested file remains open and cannot be changed by other programs until the Hollywood script has been terminated.

Could this be the same issue as this? https://forums.hollywood-mal.com/viewtopic.php?t=3782

[Flinx]

MP3 runs through a lot of different backends. Which operating system are you on? Are you using the AVCodec plugin or an OS-native streaming backend?

Tested with Linux-Arm/AVCodec (Bugreport came from Raspberry), Windows 32 and 64 Bit, Linux Mint 22 64 Bit, both with and without AVCodec, so I thougth it is everywhere, but of course I should have tell you.

Could this be the same issue as this? https://forums.hollywood-mal.com/viewtopic.php?t=3782

Maybe, but I'm not sure about the DirectShow driver, it happens on Windows with and without AVCodec (more not yet tested). I have now added a (different) mp3 file and my test script to the 7z archive, the password is still the thread subject. At the first WaitLeftMouse() the file is still locked.

[airsoftsoftwair]

Maybe, but I'm not sure about the DirectShow driver, it happens on Windows with and without AVCodec (more not yet tested). I have now added a (different) mp3 file and my test script to the 7z archive, the password is still the thread subject. At the first WaitLeftMouse() the file is still locked.

Ok, I've now tried it with Hollywood 10 and with the current Hollywood master and with the current master the file lock problem is gone so it must've been the same bug that I linked to above. So consider this fixed.

Now what was the other issue? Hollywood refusing to play the music when using a PNG image inside the ID3 tag? I'm afraid that this could a bug/limitation in avcodec.hwp which uses an FFmpeg from 2012 so the ID3 tag could be using something the parser doesn't understand. The DirectShow driver is probably even more outdated than avcodec.hwp so I wouldn't be surprised if that also has problems loading such files. So not really a Hollywood bug IMHO but a case of outdated MP3 parsers...

[Flinx]

Ok, I've now tried it with Hollywood 10 and with the current Hollywood master and with the current master the file lock problem is gone so it must've been the same bug that I linked to above. So consider this fixed.

Thanks.

Now what was the other issue? Hollywood refusing to play the music when using a PNG image inside the ID3 tag? I'm afraid that this could a bug/limitation in avcodec.hwp which uses an FFmpeg from 2012 so the ID3 tag could be using something the parser doesn't understand. The DirectShow driver is probably even more outdated than avcodec.hwp so I wouldn't be surprised if that also has problems loading such files. So not really a Hollywood bug IMHO but a case of outdated MP3 parsers...

Hmm. I tried a lot of players, even 20-year-old ones, and they all play the file. Only Hollywood doesn't. I would suspect the problem to be in the IsMusic() function - is it called too when OpenMusic() is called?
Unfortunately, I can't test any further myself. Of course, I could try to build a workaround here too by removing the tags before calling IsMusic() or open the file, but I'd prefer it if the Hollywood functions did what one expects .

But since we're at it: what development environment would be needed to build avcodec.hwp, especially on or for Windows? The FFmpeg Compilation Guide lists many variants...

[airsoftsoftwair]

Hmm. I tried a lot of players, even 20-year-old ones, and they all play the file. Only Hollywood doesn't. I would suspect the problem to be in the IsMusic() function - is it called too when OpenMusic() is called?

No, it's the other way round. Actually, IsMusic() is currently not optimized and just calls OpenMusic() to see if the file can be loaded.

Unfortunately, I can't test any further myself. Of course, I could try to build a workaround here too by removing the tags before calling IsMusic() or open the file, but I'd prefer it if the Hollywood functions did what one expects .

Easier said than done. The problem with MP3s and video files is that there are so many different encoders around that you normally will always encounter files that won't play. The only solution to this is to make sure a recent version of FFmpeg is used but that is impossible for platforms like 68k for which it is a hell of work to port because of a lack of compilers that can deliver stable code. It was already challenging in 2010/2011 when I ported FFmpeg to 68k for avcodec.hwp but back then the code surely was a lot less complex than what's currently in the FFmpeg repo. Remember that I cut it all down to something like 2 MB binary size on 68k. The current FFmpeg executable for Windows is something like 85 MB! Just to give you an idea of what has changed

But since we're at it: what development environment would be needed to build avcodec.hwp, especially on or for Windows? The FFmpeg Compilation Guide lists many variants...

No idea, I haven't done anything with FFmpeg in the last decade but building it on Windows really shouldn't be a problem at all since this should be very well supported. FFmpeg probably builds out of the box on Windows with MSYS2 or something. The real challenge is always building modern stuff for 68k