XSPF as default playlist format

As you can see, the XSPF file format became a default playlist format in both AIMP version (in AIMP v5.03 for Windows and AIMP v3.30 for Android). What is XSPF? What is the reason to make it default playlist format in AIMP?

About

XSPF (XML Shareable Playlist Format) is the XML-base file format for sharing playlists. XSPF was created by Xiph.Org Foundation and released in 2005. Main features of the format are: opensource, patent-free, cross-platform and extendable.

In AIMP, XSPF support has been implemented in v2.60 in far 2009. But the player was only able to import playlist, not export them. Export support has been added now, in v5.03 where the XSPF became a default playlist format for AIMP.

Default format

Experimenting with synchronization between devices, we decided to small start: ensure the playlist files are compatible with mobile and desktop versions of the player.

Untile recently, mobile version used binary file format (AIMPBPL) as default playlist format, while desktop version used text format (AIMPPL4). This was due to the fact that parsing a text-based playlist on Android required more time and memory than a binary one. One way to share playlists between PC and mobile is export them to the M3U8 file format using relative paths. But the M3U8 does not support even a half of the features that AIMP has. For example, CUE-splitted tracks become an invalid after export to the M3U8.

In beginning, we were planning to add the AIMPPL4 playlist format support to the mobile version of player, but revoke this idea after first tests. Tests shown that AIMPPL4 has no features for cross-platform sharing and we need to enhance it. Is it reason to create a new AIMPPL5 format that will only supported by latest versions of AIMP?

So, we chose XSPF:

  • It is open and free
  • It has a strict specification
    The specification strictly regulates the fields and data types.
    No inconsistencies.
  • It is cross-platform
    File paths always stored in URL-like form, taking windows and unix specifics into account. Relative paths are supported.
  • It is extendable
    We will able to store a custom data to the file. For example: smart-playlist’s preimage, appearance and grouping settings.
  • It is supported by other players
    Resulting playlist can be opened in any other player that supports for XSPF, not only in AIMP.

Cross-platform

Now, playlist became a shareable between mobile and PC version of AIMP. It doesn’t matter if you saving them using absolute or relative paths – the main thing here is that they are shared along with the music folder.

Additionally, now shared following things:

  • CUE-splitted tracks
  • Smart-playlists based on folders or playlists
    Note that mobile version has less number of smart-playlists features than PC’s one. It is temporary limitation, I hope.

So, migrating to the XSPF became a first step towards synchronization between mobile and desktop versions of AIMP.

Performance

During first tests, we have found a main disadvantage of the format: XML markup takes to much space in XSPF specification. It leads to increase the size of resulting playlist files and increase the playlist loading time.

For example, the playlist contains a 50 000 of audio files with fully filled tags (all tag fields supported by AIMP were not empty):

FormatFile size (MB)Loading time (sec)
XSPF37.21.6
M3U86.80.4
AIMPPL420.70.9
Comparing formats performance

Is it a big price for cross-platform?

List of all AIMP’s extensions for the XSPF file format and their descriptions you can find in the AIMP Extensions for XSPF document that included to the SDK package.

12 thoughts on “XSPF as default playlist format

  1. Ta2i4

    Мне кажется, что плата за кроссплатформенность небольшая. Учитывая, что сейчас редко кто задумывается об объемах пространства, занимаемых приложениями, и их аппетиты постоянно растут.

  2. Green

    А почему не захотели расширять бинарный формат и обучить ему настольный aimp? Он, наверное, вообще молниеносно загрузился бы?

    1. Artem Post author

      Во-первых, бинарный формат плох тем, что случись чего – вы не сможете просто открыть плейлисте в блокноте и подправить его.
      Во-вторых, свой формат – это снова замыкание на себе.

      1. Green

        Оно и xml не каждый сумеет поправить, но всё же сбои это крайне редкий случай.

        С “замыканием на себе” по-моему нет ничего плохого, если это обеспечивает высокую производительность. Тем более, что экспорт в популярные форматы же никуда не пропадёт.

        Не рассматривали protobuf или bson как альтернативу бинарному формату?

        1. Artem Post author

          Оно и xml не каждый сумеет поправить, но всё же сбои это крайне редкий случай.

          Пути к файлам – сможет, и этим довольно часто занимаются, на самом деле.

          Не рассматривали protobuf или bson как альтернативу бинарному формату?

          На их основе есть стандарты плейлистов?

          1. Green

            Есть xspf основанный на json: https://xspf.org/jspf Ну а json же лёгким движением руки превращается в bson.

            Протестируйте, возможно этот вариант окажется оптимальным?

            1. Artem Post author

              Да, это я видел, но там именование полей остается тем же (длинные названия по сути и являются главным раздувающим фактором).

              1. Green

                По размеру файла может там всё плюс-минус останется таким же, но вот скорость парсинга bson должна быть выше.

                1. Artem Post author

                  Согласно моим замерам, тормозит больше сравнение строк, нежели сам разбор файла. Плюс, не забывайте, что в статье я использовал довольно большой плейлист с полным объемом данных.

  3. Алексей Долматов

    “Большая ли это плата за кросс-платформенность?”

    По сравнению с собственным форматом разница в полтора раза должна быть ощутимой на больших объёмах. Другое дело, что нужно сравнивать заметна и неприятна ли эта разница при реальном использовании плеера, при открытии и импорте нескольких плейлистов.
    Сравнивать с M3U(8) не вижу особой пользы. Стандарт файла позволяет хранить меньше данных, а использование альтернативной структуры может поломать совместимость с другими программами. При этом нужно учитывать чтение данных (тегов) из самих треков на основе плейлиста.

    “XSPF стал форматом плейлистов по умолчанию”
    Есть сомнения, что проверка была выполнена достаточно объективно. AIMP для Windows в своей папке продолжает хранить, а значит и использовать, плейлисты в собственном формате. Можно протестировать работу плеера с использованием другого формата внутри себя. Это позволит исключить влияние парсинга для преобразования плейлиста при открытии, что в перспективе может увеличить отзывчивость плеера.
    Если будет заметная польза от такого изменения, то можно будет рассматривать иные аспекты оптимизации работы с таким форматом. В зависимости, насколько они (аспекты-алгоритмы) могут влиять на производительность с разными форматами.

    1. Artem Post author

      Есть сомнения, что проверка была выполнена достаточно объективно

      Что вызывает сомнение? В своей папке плеер хранит в старом формате по двум причинам: обратная совместимость и производительность. К тому же, пользователь туда не лазит, поэтому там мы можем хранить плейлисты хоть в базе данных или в бинарном формате (как фубар делает).

Leave a Reply