.m3u File Type

[Skyy Mansour]

M3UMP3 URL) is an audio playlist file stored with the .m3u extension. M3U is not an actual audio file, it just points to audio and sometimes video files. M3U was developed to be used with Winplay3 software by Fraunhofer. It is also supported by various media players and software.

M3U (MP3 URL[1][2] or Moving Picture Experts Group Audio Layer 3 Uniform Resource Locator[3] in full) is a computer file format for a multimedia playlist. One common use of the M3U file format is creating a single-entry playlist file pointing to a stream on the Internet. The created file provides easy access to that stream and is often used in downloads from a website, for emailing, and for listening to Internet radio.

Although originally designed for audio files, such as MP3, it is commonly used to point media players to audio and video sources, including online sources. M3U was originally developed by Fraunhofer for use with their Winplay3 software,[4] but numerous media players and software applications now support the format.

An M3U file is a plain text file that specifies the locations of one or more media files. The file is saved with the "m3u" filename extension if the text is encoded in the local system's default non-Unicode encoding (e.g., a Windows codepage), or with the "m3u8" extension if the text is UTF-8 encoded.[9]

Apple used the extended M3U format as a base for their HTTP Live Streaming (HLS)[12] which was documented in an Independent Submission Stream RFC in 2017 as RFC 8216.[13] Therein, a master playlist references segment playlists which usually contain URLs for short parts of the media stream. Some tags only apply to the former type and some only to the latter type of playlist, but they all begin with #EXT-X-.

The Unicode version of M3U is M3U8, which uses UTF-8-encoded characters. M3U8 files are the basis for the HTTP Live Streaming (HLS) format originally developed by Apple to stream video and radio to iOS devices, and which is now a popular format for adaptive streaming in general.

The current proposal for the HLS playlist format acknowledges two media types which it treats as equivalent: application/vnd.apple.mpegurl and audio/mpegurl.[14] Likewise, these are the two types recommended for HLS use by Microsoft.[17]

For non-HLS applications, no media types were standardized or registered with the IANA, but a number of media types are nonetheless associated with the historical and ongoing use of the M3U and M3U8 formats for general playlists:

These types, plus application/vnd.apple.mpegurl and application/vnd.apple.mpegurl.audio, are supported for HLS applications by (for example) Microsoft's Windows 10[17] and Internet Explorer 9,[18] and LG's WebOS.[19]

This is an example of an extended M3U file on the Windows platform. Sample.mp3 and Example.ogg are the media files. 123 and 321 are the lengths in seconds.[20] A length of -1 or 0 may be used when the media file is a streaming file, as there is no actual, predefined length value. The value after the length is the title to be shown, which is generally the same as the location of the file which is on the second line. On the macOS and Linux platforms, Unix paths are used.

This example shows how to create an m3u file linking to a specified directory (for example, a flash drive, or CD-ROM). The m3u file should contain only one string: the path to the directory. After starting, the media player will play all contents of the directory:

Here is another example, using relative format. The M3U file is placed in the same directory as the music, and directories must be preserved when moving the playlist to another device if subdirectories are used. This method is more flexible, as it does not rely on the file path staying the same.

It is my (very limited) understanding that file does not include file extensions in its tests to determine a file type. You may get something more like the result you are expecting from something like

3. Tried putting the .m3u on the root and also in the /MUSIC directory. I see that the Fuze will find the .m3u and show it in Playlists whether you put it on the root or in the /MUSIC directory. By the way, I did change the path depending on where I tried the playlist.

Backslashes are mandatory. FWIW, I put my hand-crafted M3Us in the Music directory and make the paths relative to that. I doubt they have to be there, but that is where my first playlist was located when I finally got it working and I was sick of messing with it.

If you are still struggling and are using Windows, you could search on this forum for a program I wrote called Genre Playlist Creator. If you run that it will autmatically create m3u files so you could at least check that they are working OK.

I have a html page, which references local .m3u files using file:///In the past, clicking on such a link ran Winamp (default mp3/m3u player on my system)Currently, files are opened as a plain text, and Firefox does not care about the extension.

HI, possibly reinstall Winamp at let it hook to everything when asked when do a custom install. That I would hope would shove the file type into Options --> Applications. If not looked there please do so and see if it is. If is tell Firefox what to do with it it not do with it.

That's not my problem - it's in the Options/Applications and it works, if the m3u file is served from link.It does not work when it's served by local file:/// link. For some reason FFox thinks it has mimetype text/plain.

I have seen that Firefox doesn't handle the M3U playlists files as it

does on internet explorer.

If you embed a code like this:

or with

it won't load, and display a message saying that another plugin is

needed. When you click on it, nothing is recognised and you must choose

manually.

So I think that this M3U filetype sould be recognised by Firefox like

IE does, and that this is a bug. Can someone confirm ?

I have tried with the latest firefox version.Thanks,

Daniel

MIME types audio/mpegurl and audio/x-mpegurl are both handled by the

Crescendo 5.1 plugin. I know it is hard to find, however a request in the

multimedia test group should get a reply with the URL of a server

dispensing the universal NP/IE version of Crescendo Max. That was the last

version released before Liveupdate closed shop.--

Ron K.

Don't be a fonted, it's just type casting.

--

Files From The Not To Swift Department . . .I was checking out at the local Wal-Mart with just a few items and The

lady behind me put her things on the belt close to mine. I picked up

one of those "dividers" that they keep by the cash register and placed

it between our things so they wouldn't get mixed. After the girl had

scanned all of my items, she picked up the "divider", looking it all

over for the bar code so she could scan it. Not finding the bar code

she said to me, "Do you know how much this is?" I said to her "I've

changed my mind, I don't think I'll buy that today." She said "OK,"

and I paid her for the things and left. She had no clue what had just

happened.

Hello all,

Thanks for the help and suggestions from everyone.I have tested by forcing the type="application/x-mplayer2" suggestion

from Roland. This works on my computer, it is already a good point.

However, as Roland said, this won't work on a Linux station or any

computer without Windows Media Player.

My goal is to have a standard HTML 4 tag which makes sure that the

browser will recognise in all cases the M3U playlists and display them

correctly, using any player which can recognize the filetype (xine,

Mplayer, etc...), this is up to the browser to choose. This should make

the play be independent of the tag, ensuring that everyone will be able

to listen to my music (the main goal).Using the tag seems to me a wise thing as it is recognised by

Netscape and IE and FF I believe, and seems to be the standard tag to

use for this purpose.

Now, the problem is that using the type="audio/x-mpegurl" HTML

directive, this makes FF not recognise the MIME type at all, and asks

for installing another plugin, which he even didn't know which on eot

suggest.

This is my point: It seems to me that there is a bug in the way FF

handles this. To my opinion, FF should be able to know what player

which is already installed on the system can handle this

="audio/x-mpegurl", and even only the 'm3u' file extension, and it

ins't the case.Can someone confirm that it is a bug, and tell the developper's

community to add this in the bug list if it is really the case ? I

didn't find how to report a bug on the Firefox website.Thanks,

Daniel

[1]Unfortunately FF still signals a missing plugin for the outer

tags if their content type isn't supported. This seems to be a bug to me.

Alternatively you can use JavaScript to insert the appropriate

tag (only one), but of course nothing will be played if the client

browser has disabled JavaScript.Here's the JS I've been experimenting with:

> > RolandHello, Roland.Thank you for this suggestion. I was so happy to see such an

implementation of the nested object tag for failure tests....Unfortunately, I did try it right away and it seems that Microsoft IE 6

does't follow the w3c specification on this, because there were two

instances of the music playing together, with about 50ms of delay one

between each other. Have you seen that behaviour also ?

That is very sad, it would have been the real solution if it worked..Else, do you know how I could report the firefox mimetype bug, is there

a bugzilla for firefox ?Thanks,

Daniel

I am not sure this is a bug. What you have is a probable case of no

plugin registered to handle the MIME type and pass the data stream to the

plugin for processing. Look through your about:plugin listing for the m3u

MIME type. Then look through your Options dialog and review the Download

Actions listing. If the MIME types are not showing, click on the arrow in

top right corner of the pane to unhide them.

3a8082e126