Minimum reproducible wikitext:

<score vorbis="1">
{a}
</score>
[[File:Example.ogg]]

I can reproduce anywhere with that code.

The issue has also been reported on itwiki.

Somehow, the same code works here but here doesn't

Somehow, the same code works here but here doesn't

That's because of T295514: Score audio uses different players depending on whether the page has other embedded media.

In T363630#9750975, @Nardog wrote:

Somehow, the same code works here but here doesn't

That's because of T295514: Score audio uses different players depending on whether the page has other embedded media.

That task only reports inconsistent behaviour. The indeterminate progress bar issue is occurring in that example.

I was just explaining why it works in your first example and it doesn't in the latter. The presence of other embedded media on the same page triggers the use of the VideoJS player for Score-generated audio.

If you add ?useskin=monobook&debug=1 you see the blue progress bar that is obscured in latest default Vector. When I click the broken score player's play button I see jQuery.Deferred exception: title is undefined in Firefox browser console, coming from doPropagation of a requestIdleCallback handler that some module is ready.

Dubious source code analysis follows...

The mw-ext-score <div> contains an <audio> tag with

<source src="//upload.wikimedia.org/score/t/s/tsi3u4jmg0p4ocq22jukqyia6o9es1o/tsi3u4jm.mp3" type="audio/mpeg">

TMH runs and wraps this with its

<span class="mw-tmh-player audio mw-file-element"><audio playsinline="" preload="metadata" class="video-js">

When you click play, TMH puts up a <div class="mw-tmh-player-interstitial"> and calls infuse() in in https://test.wikipedia.org/w/load.php?debug=1&lang=en&modules=ext.tmh.player.inline%7Cext.tmh.video-js&skin=monobook&version=ztntf which "Takes the HTMLMediaElement of the InlinePlayer and infuses it with JS (videoJS) to enrich the element." At line 192 of this

		const resource = this.videoplayer.getAttribute( 'resource' );
		const resourceTitle = resource ?
			decodeURIComponent( resource.slice( resource.lastIndexOf( '/' ) + 1 ) ) :
			this.$videoplayer.data( 'mwtitle' );
		this.playerConfig.mwTitle = mw.Title.newFromText(
			resourceTitle, NS_FILE
		);

There's no resource, so it tries to use this.$videoplayer (Note $videoplayer not videoplayer or videojsPlayer); but I think the $videoplayer isn't set up yet, so ??? weird deferred promise stuff happens. Anyway, resourceTitle ends up undefined (note, not null), and then mwTitle.newFromText() is presumably unhappy. If I break on exceptions in Firefox's debugger, there's an exception in

parse = function ( title, defaultNamespace ) {

called from

Title.newFromText = function ( title, namespace ) {

because parse() is fiddling with an undefined value.

Anyway, eventually the jQuery.Deferred.exceptionHook runs and it prints "jQuery.Deferred exception: title is undefined". Interestingly Title.newFromText() has the comment "Constructor for Title objects with a null return instead of an exception for invalid titles", but it does trigger an exception if the title isn't a string.

My crappy analysis suggests two possible fixes.

1. Make Title.newFromText() even more robust; it or parse() can check if (typeof (title) !== 'string' and bail. However, later on this causes grief in InfoButtonPlugin which naively tries to access title.getMainText() when title is null, so that would have to be tweaked as well. I think this makes a button that links to the mediawiki File: object for the audio file, but there isn't an info button in an inline videoplayer, so it seems wasted work in this case.
2. Give this.videoplayer a resource attribute, e.g. at line 119 in infuse() where it gives it a preload attribute. If before line 192 I push a resource attribute into this.videoplayer in the Firefox debugger by running this.videoplayer.setAttribute('resource', 'dummy'); there's no exception, the browser's audio player is replaced by this videoplayer, and the music plays. Maybe setting the resource attribute to the <source src> attribute would be more correct.

Hope this helps; I have little idea WTH is going on.