There seems to be a strong preference for MP3 files rather than OGG. I hope this would also take care of some other bugs: T50029 as an example.

The very simple way is just to change the TiMidity command to convert to MP3. However, I think the conversion should be spun-off to TimedMediaHandler (as suggested in T135597: Move MIDI to audio conversion from Score into TimedMediaHandler).

Yes, just like the OGG files, it would have to go through TMH, but it would be better for the extension if it were just to pass the MIDI file and have TMH deal with conversion.

Is this really a task that can be done by a GCI student? It sounds more complicated, at least to me, but I probably do not really understand what needs to be done :) (hey: That could also be an indicator, that some more explanation for a GCI student is missing, too, probably you can give some more hints where to look, where to start and what exactly needs to be done? :))

Moving the conversion out to TMH is pretty hard because it requires retooling a bunch of weird code in TMH. Just switching from ogg to mp3 would be much easier.

@Florian as far as I understand the task is to add an option to convert midi files into MP3 files, but this needs some clarification about the used tool, as Timidity doesn't have a native option for MP3 conversion. This can be done by checking the filename extension in my opinion, should be the easiest way.

@Florian: It sounds more complicated, at least to me, but I probably do not really understand what needs to be done :)

I added indications of what has to be done in the task description. It wasn't clear I admit.

@brion: Just switching from ogg to mp3 would be much easier.

That is the topic of this bug. Work on TMH is badly needed though (especially if there's "weird code")

@divadsn: Timidity doesn't have a native option for MP3 conversion.

That's the big problem, and here's another reason to migrate over to Fluidsynth (after testing and alternative-checking). I don't understand your point about checking the filename extension TBH. It's to replace vorbis, not as a new option.

However, seeing that MP3-conversion is only supported on Windows, I'll put the GCI task on hold.

@Ebe123: However, seeing that MP3-conversion is only supported on Windows, I'll put the GCI task on hold.

We could still do a pipe out to lame and convert that way on Linux, at least it's worth a try IMO.

@Ebe123 Thanks for the feedback. I saw the edit of the task. I think it's now more clear what a student needs to do. I've published it and hope that a student will take this task, as I think it can be nice to hack at this problem :D Good luck to anyone who might take it :P

In T181875#3868362, @divadsn wrote:

@Ebe123: However, seeing that MP3-conversion is only supported on Windows, I'll put the GCI task on hold.

We could still do a pipe out to lame and convert that way on Linux, at least it's worth a try IMO.

I agree that piping it into an mp3 encoder seems like a good approach.

In my opinion we should wait until T181897 hasn't been solved, just to avoid double work.

There is very little double work here. The result of T181897 is unknown, but the output format of both can be the same, so the LAME command would most probably stay the same. The other work to make it mp3 would have to be done regardless of program. As such, doing this before possibly migrating to another program makes less work when time comes to migrate. We can parallelize these tasks without having (non-trivial) double work.

Change 402590 had a related patch set uploaded (by Divadsn; owner: Divadsn):
[mediawiki/extensions/Score@master] Use MP3 with LAME instead of OGG for MIDI conversion

https://gerrit.wikimedia.org/r/402590

I ended up generating a temporary wav file and then converting the wav to mp3, the rendering time shouldn't be much affected by that "workaround", I can run later a benchmark same as I did with the comparison before.

Here are some testing results.

Fluidsynth to OGG

Page loading time when generating:

Page loading time after:

Fluidsynth to MP3 using WAV and lame

Fluidsynth to MP3 using lame when generating:

Page loading time after:

Conclusion:

Aside of the slight increased page loading time when generating the file, there is no difference when the page with the generated audio file is being loaded.

Check T49533. It'd be odd if it were only on OGG.

@Ebe123 I don't exactly know if there is a difference between, but I also see only the stock audio player.

Change 402590 merged by jenkins-bot:
[mediawiki/extensions/Score@master] Use MP3 with LAME instead of OGG for MIDI conversion

https://gerrit.wikimedia.org/r/402590

MP3 is no longer patent encumbered because it is very old (more than 20 years). Why should we desire it? It's not efficient (bad quality or high bitrate), it's worse than Vorbis. Only IE users would have a better experience: the overwhelming majority would experiment a worse experience (IE+Edge < 9%).

I'd find more interesting Opus: we could take the same sound quality (quality is not very important for a robotic performance), save a lot of bandwidth and promote a better standard.

@Stemby MP3 files are better for mobile users from my experience when it comes to loading time and file size.

You forgot all the Apple users, especially those on mobile who can't install an alternative browser. That's 23% of our traffic. Vorbis is an audio compression standard from the same generation as MP3. It might be slightly better but the difference is marginal and not worth taking the ability to play audio from one third of our readers.