How can I control the filename when HTML5 audio is saved by the user?

Question

On my blog a radio channel can be listened, either the live broadcast, or the previous broadcasts from the archive of the channel by a timetable.

I would like to achieve that visitors would be able to save these older broadcasts with their distinctive programme name. When visitors click on the given timestamp, the appropriate or appropriately parameterized URL is loaded into a HTML5 audio object's source.

There are two kinds of URL formats, the first one, only for the current day: http://example.com/20190707080000/20190707090000/channel1.mp3
In this case I can exploit the following hack: instead of the latest URL, I load the following URL into the audio player: http://example.com/20190707080000/20190707090000/channel1.mp3/Title_of_the_programme.mp3

In this case the visitor will be able to save the listened program by the given filename: "Title_of_the_programme.mp3".

The other URLs, for the other days, than the current day, are different, as those programmes were already archived, maybe in a lower bitrate and/or format: http://example.com/2019/07/06/channe11.mp4?start=28800&end=32400 "start" and "end" parameters are for the given second of the day, when the actual programme starts and ends.

In this second case the aforementioned hack doesn't work any more, so I can't load a similar URL into the HTML5 audio player: http://example.com/2019/07/06/channel1.mp4?start=28800&end=32400/Title_of_the_programme.mp4

Unfortunately it doesn't work, when I click on the save as button of the HTML5 audio player, the filename will always be "channel1.mp4", which is suboptimal.

In both cases the full programme is served at once for a GET request.

The "download" attribute, "a[download]" for the HTML "A" element or the same attribute for the HTML5 "audio" element also doesn't work, due to the browser's same origin policy: the domain of the radio is of course different than my blog domain.

Fetching the resulting media file with an Ajax call (XMLhttprequest) into a browser blob also doesn't work, due to the same origin policy. The server of the radio of course doesn't provide the appropriate header field for these Ajax calls: "Access-Control-Allow-Origin: *".

The response headers of the radio programme URLs doesn't contain a "content-disposition" header field, so the filename must be determined by the URL itself.

Alaska

Answer 1

Accidentally I have found the solution, which is simply the "title" attribute:

<audio id="track" controls="controls" autoplay="autoplay" title="The_title_of_te_programme.mp4">
  <source id="mp3source"  src=" http://example.com/2019/07/06/channel1.mp4?start=28800&end=32400/Title_of_the_programme.mp4" type="audio/mpeg">
</source></audio>

Maybe useful for others too. Update: Title attribute method works in Chromium. And a[download] method seems to be working in Opera (at least in that version I have, Opera 45.):

<a href="http://example.com/20190707080000/20190707090000/channel1.mp3" download="Title_of_the_programme.mp3">

Firefox still need to be resolved.

Alaska

Did you try http://example.com/2019/07/06/channel1.mp4/Title_of_the_programme.mp4?start=28800&end=32400? With the approach in your solution, the value of the end query parameter will be parsed as 32400/Title_of_the_programme.mp4 – Paraprofessional

Yes, I tried it, but it isn't work. The answer from the server in this case is an error string. – Alaska

If title already works, then you should remove the /Title_of_the_programme.mp4 from the end query parameter, otherwise you'll get the wrong range of audio. – Paraprofessional

Yes, title attribute works, but only in Chromium, not in Firefox, nor in Opera... – Alaska

A similar problem, this doesn't help? #44061854 – Alaska

No. The problem isn't in creating the Blob, the problem is getting what you need in place of that string "file" – Paraprofessional