4.13 This Music Track No Loger Works

[Enjay]

Pretty much as the title says.

Load up the linked file into Doom2 and start the game. The music lump in the file replaces d_runnin. In GZDoom 4.13 I get the following message at the console.

Unable to load : Unable to identify as music

If I load the file into a dev version of 4.9 that I still have kicking around on my hard drive, the music works. Sorry, I don't have the capacity to narrow it down more closely than that at the moment.

https://www.aspectsweb.co.uk/enjay/Temp ... NoWork.pk3

Edit: I have found a few other music tracks that used to work, but no longer do - giving the same message as above. I can provide more examples if needed.

[Gez]

For what it's worth, SLADE also fails to identify it as playable music.

[Rachael]

Opening the file in a hex editor it appears to be an MP3 file but I don't know why it fails to identify.

[Chris]

It seems to work for me, using a recent Git build (GZDoom commit 8e4080f8d16695b9c26475a1732feda2c7efe7f8, ZMusic commit 519b76b6e7a89752757732561ff2cada3cd7d221).

Looking at the file, it starts with an ID3 tag followed by a whole lot of nothing. The MP3 data doesn't start until the 3,370th byte, that makes me think perhaps the decoder gives up trying to figure out what it is before reaching the MP3 bytestream for some reason.

[Enjay]

Interesting. It seems as if the file is at least a bit odd then.

Like I said, I have now found a few files that show the same problem. I know for certain that not all of the files came from the same source but there are some common factors. e.g. several of the files I have came from the game Dredd vs Death. I don't *think* the files in the game are MP3s, so something must have been done to convert them at some point. The file that I provided, sounds like a track from Kinsie's "Null Face to Face" mod. If it is, then from memory, the files in that are tracker modules of some sort. So, again, there must have been some converting going on there too in order to create an MP3. I have no idea what or who converted any of the files.

I'll check out the git build when I get a chance but it's interesting that older GZDoom versions played it OK, the current official version doesn't and then a newer build does again.

[Chris]

I'll check out the git build when I get a chance but it's interesting that older GZDoom versions played it OK, the current official version doesn't and then a newer build does again.

It's also possible there's something particular about my build set up. Since I'm on Linux, it could be related to me using a different release of libsndfile (1.2.2 according to my package manager) or libmpg123 (1.32.7). I don't know how this is put together on other OSs, so maybe they have different versions that have trouble auto-detecting the file format.

[Enjay]

gzdoom-x64-g4.14pre-16-g261881e0d gives me the same result as 4.13. i.e. the music does not play and there is the error message at the console.

[Gez]

Looking at the file, it starts with an ID3 tag followed by a whole lot of nothing. The MP3 data doesn't start until the 3,370th byte, that makes me think perhaps the decoder gives up trying to figure out what it is before reaching the MP3 bytestream for some reason.

I can confirm this is the case at least for SLADE:

Code: Select all

	// Check for empty wasted space at the beginning, since it's apparently
	// quite popular in MP3s to start with a useless blank frame.
	size_t s = 0;
	if (mc.size() > 0 && mc[0] == 0)
	{
		// Completely arbitrary limit to how long to seek for data.
		size_t limit = std::min<size_t>(1200, mc.size() / 16);
		while ((s < limit) && (mc[s] == 0))
			++s;
	}

Of course, in SLADE's case, there's also a performance requirements since it basically needs to identify every single lump when opening an archive. So it makes sense not to bother with trying to validate a reticent MP3 for too long.

[Graf Zahl]

If this happens in GZDoom you will have to report it to libsndfile. We do not attempt any MP3 detection ourselves, and I even think libsndfile just defers to libmpg123.

[Enjay]

I can see all those zeroes in a Hex editor. I wonder how it ended up like that?

I don't suppose it makes much difference, but here's another sample.

https://www.aspectsweb.co.uk/enjay/Temp ... oWork2.pk3

(Same thing, load and it replaces d_runnin.)

The reason I'm uploading this one is that SLADE identifies it as an MP3 and plays it, but GZDoom does not.

Looking at it in a hex editor, it doesn't seem to have an ID3 header, but it does have lost of zeroes near the start, a few non-zero values and then a bunch more zeroes before the data starts properly. So, probably just a slightly different manifestation of the same cause.

[Graf Zahl]

You won't get anywhere with this here. Like I said, we rely on libsndfile for identification.

[Enjay]

Yep, no worries, and understood.
I only included the second file in case anyone was interested in seeing it, and I was busy typing my post when our posts crossed.

For what it's worth, I loaded up the files in a sound editor and saved them again. This cleared all the empty bytes and the resulting files work in GZDoom.

I have no idea if there are any projects in the wild with similar MP3s but I guess the possibility exists.
If libsndfile is failing to identify files like this, then they may be interested in looking at it.

I have raised an issue on libsndfile
https://github.com/libsndfile/libsndfile/issues/1039
I'm no expert on this, so if anyone has any corrections or anything to add, please be my guest.

[Chris]

FWIW, it seems libsndfile isn't detecting either of the files for me either, meaning it's libmpg123 that manages to handle the files. I'd still call this an issue in libsndfile either way, if nothing else the ID3v2 tag in the first file should give it a confidence boost that there's supposed to be audio even if it may have to search deeper to get to it (the second file just has a lot of nothing at the start before reaching what appear to be dummy frames with text info before the audio data actually starts; libsndfile may just need to search a bit more by default to find it). Looking at its source, it uses libmpg123 when compiled with mpeg audio support, and seems to explicitly set the MPG123_NO_FRANKENSTEIN flag that makes it more strict about the mp3 bytestream. So I guess older GZDoom/ZMusic fell back to using libmpg123 directly without using that flag (or used an older libsndfile that used an older libmpg123 that didn't have that flag yet), allowing it to recognize the file, while newer versions rely on libsndfile with a newer libmpg123 with that flag, which is more strict and reject it.

[Graf Zahl]

zmusic still has direct libmpg123 support, but since libsndfile handles this case the DLL is no longer included. What does it do if you copy one from an older GZDoom into the folder?

I wonder what tool has written these files.

[Enjay]

Comment from the issue thread that I raised in GitHub:

Seems it might be due to mpeg_decoder_init explicitly setting the MPG123_NO_FRANKENSTEIN flag, making libmpg123 more strict with the bytestream and causing it to reject the files since they start with 0 data and junk. libmpg123 is otherwise capable of playing the files, but not through libsndfile, and that flag stands out as a possible reason.