Как стать автором
Обновить

Комментарии 23

1. Можно ли автоматически заполнять Title из имени файла?
2. По-моему, не нужно над каждой строкой трека писать названия полей, достаточно одного заголовка сверху, а то при 10 треках половину экрана занимают названия полей
3. После нажатия «Add album» долго крутился бублик, но ничего заметного после его исчезновения не произошло — то же самое окно «Share an album».
1. Лучше на основе метаданных, вроде id3 тегов. Названия файлов, насколько я помню, не все символы поддерживают.
2. Форма сейчас на переработки, учтём.
3. У себя на компьютере тоже такое замечал, пока не разобрался.
Мне вот интересно что произойдет если два одинаковых файла получат один хеш в сети. Как сеть избегает таких конфликтов?
использовать сразу несколько подписей разными алгоритмами?
Если два одинаковых файла получают один и тот же хэш, значит IPFS работает как задумано.
Ну я бред конечно написал, имел ввиду разные файлы.
Смешно, но я Вам и ответил, имея ввиду разные файлы)
negamaxi, вы пользуетесь какими-либо закрытыми музыкальными торрент-трекерами (желательно на gazelle)? Возьмите все лучшее с них: автозаполнение информации об альбоме из musicbrains, конкретные разрешенные форматы, фиксированные правила по называнию композиций и файлов, теги к каждому автору и альбому, система визуального отображения похожих исполнителей, система заявок.

Я думаю над подобной системой уже 2 месяца. Основная идея: вся музыка бесплатна, хранится в распределенном виде между всеми участниками системы, с избыточностью. Особенности системы:
* Децентрализованные метаданные (информация о всей музыке в системе) с централизованным управлением
Метаданные должны синхронизироваться между всеми участниками обмена, но изменять их могут только администраторы. Это нужно для того, чтобы у нас не было дубликатов, низкокачественных транскодов, спама.

* Жестко заданные форматы и централизованный транскодинг
Современные аудиокодеки, такие как Opus, отлично звучат при 128 Кбит/с, что заметно сократит требования к пропускной способности канала, особенно если замахиваться на мобильные устройства, где либо оплата по трафику, либо ограничения трафика.
Конечно, не нужно ограничиваться только Opus 128, должен быть выбор из «обычного» качества (Opus), «высокого» качества (Vorbis Q8), и FLAC. Централизованный транскодинг из FLAC в Opus и Vorbis.

Opus 128 kbit/s:
Пример 1: FLAC (22.9 МБ), Opus 128k (3 МБ)
Пример 2: FLAC (25.2 МБ), Opus 128k (3.2 МБ)

* Прямые платежи авторам песен и «общие» платежи а-ля Flattr
Я часто покупаю музыку напрямую у музыкантов. Нужно, чтобы в системе у любого музыканта была возможность добавить свой кошелек какой-то криптовалюты. Нравится музыка — отправляешь средства напрямую музыканту, без посредников и комиссий (но это дожлен быть абсолютно точно не Bitcoin, из-за его чрезвычайно высоких комиссий и на текущий момент, и даже год назад).
Также, общие платежи. Пользователь вносит на общий счет условные $10, система запоминает, музыку каких музыкантов вы прослушивали в течение месяца, и разделяет $10 между всеми авторами прослушанных композиций.

* Продвижение исполнителей и альбомов
Это ­— неотъемлемая и важная часть системы. Каждый день будет уникальный «альбом дня», который будет видеть любой пользователь, и, таким образом, знакомиться с новыми исполнителями. Исполнители должны будут подтвердить свой аккаунт, и только после этого смогут добавить свой адрес криптокошелька, чтобы пользователи могли им перечислять деньги. Подтверждение аккаунта требует от исполнителя оставить заметку (в соц. сетях или где-то еще), что его музыка доступна в системе, и что ее там можно слушать бесплатно. Исполнители будут получать деньги из счета для «общих» платежей, а также прямые платежи, если кому-то музыка очень понравилась.

* Работа только через анонимизирующие оверлейные сети
Данные должны передаваться от слушателя к слушателю только через анонимизирующие оверлейные сети, построенные поверх интернета. Нужно это для двух целей:
  1. Невозможности отслеживания конкретных слушателей правообладателями, чтобы избежать штрафов за нарушение DMCA, как это сейчас в США, Великобритании, Германии и других странах за раздачу контента через Bittorrent.
  2. Улучшения связности из-за отсутствия необходимости иметь «открытый» порт и маршрутизируемый IP-адрес.
Все это можно сделать на основе Tor, он, вопреки распространенному мнению, очень быстрый в качестве оверлейной сети (а медленные у него только Exit-ноды). Причем, те пользователи, которые находятся в странах, не подверженных DMCA, могут отключить анонимизицию (перевести Tor в режим 1 Hop).

Если все реализовать грамотно, подобная система серьезно изменит музыкальную индустрию, я в этом совершенно уверен.
Как сказал мой друг, идей на пять лет разработки)

Пока разногласия только по вопросу централизованного формирования метаданных и транскодинга. Не буду спорить, что на качестве данных это скажется положительно, но сначала будут опробованы все децентрализованные способы формирования и развития экосистемы. Централизованные решения если и будут, то в качестве опций.

Я не понимаю одного, плеер в названии это маркетинговый ход? Чем эта система отличается от других систем распределённого хранения файлов?

Система хранения файлов — IPFS.
«Плеер» в данном случае получается системой каталогизации и воспроизведения файлов, хранимых в этой системе. Как Google Music, с которым и сравнивается.

Для большей дедупликации mp3 файлов их можно делить на блоки особым образом: id3 в отдельных блоках, музыка в отдельных. Тогда у одинаковых mp3 с изменёнными тегами в теле будут одинаковые блоки. Ну и желательно использовать raw блоки для файлов. Тогда можно будет публиковать без копирования в репозитарий и вытаскавать из репозитария с републикацией тогда данные не будут занимать двойной объём.

Как раз читал на днях Ваши статьи. До этого про возможность хранить ссылки не знал, будем пробовать.

По поводу отделения тегов от аудио-данных — метаданные и так хранятся в dag-обёртке, так что я бы уже говорил о выбрасывании встроенных тегов за ненадобностью. Но это уже надо с разными контейнерами / форматами разбираться. Либо, можно как ValdikSS предлагает, в один целевой формат всё транскодировать.

Раз зашли на огонёк, при помощи IPFS можно как-нибудь стримить аудио с подстройкой качества? Самое простое, что приходит в голову — держать в dag-объекте для каждого трека массив альтернативных форматов (mp3-256, mp3-320, FLAC ...) и давать возможность пользователю указывать при проигрывании предпочитаемый, но это как-то аляповато.

Выбрасывать теги из файла не советую так как кто-то может эти файлы закидывать себе на плеер потом. Для mp3 достаточно научиться читать фреймы. Самая большая непрерывная цепочка фреймов в файле и будет музыкой. Остальное теги различного формата. Код для распознования mp3 фреймов можно из Shareaza перевести.


Примерно так думаю и работают интернет плееры. Им даётся список потоков в разном качестве и они переключаются между ними вовремя воспроизведения. Есть различные форматы. Вот информация в вики по этому вопросу Adaptive bitrate streaming.

Народ, кто-нибудь видел хорошую статью на русском, как в IPFS компьютеры находят друг друга?

Ведь в общем случае, если допустим в сети только 2 разбросанных по бескрайнему интернету компа без некой «подсказки» они друг друга не найдут… только перебор всех айпишников. У торрентов такая подсказка — это трекеры (слабое звено), хранящие БД адресов пиров, а что использует IPFS?
Я не так давно узнал, что DHT так же работает. Там есть такое понятие как bootstrap nodes — обычные сервера, у которых приложения получают первый список других участников распределённой сети. Потом уже эти сервера никак не участвуют, но всё же.

Альтернатива — действительно перебор ip. Я его как-то пробовал ради эксперимента и первого DHT-пира нашло минут через пять, так что тоже рабочий вариант. Но не для варианта с двумя компами, само собой.

Я так понял, чтобы стать участником любой распределённой сети нужно знать рабочую точку входа.
Ну да, похоже общая схема именно такая. Сначала известная рабочая точка входа, которая скидывает всех известных ей участников, а дальше через них можно уже свою карту сети строить/обновлять.
Это вообще работает?
Версия 1.3.0 никаких альбомов не находит («Albums will appear gradually, as they are discovered»)
Версия 1.4.0 дает ошибку
NON-ZERO EXIT CODE 1 WHILE RUNNING: C:\USERS\X\APPDATA\LOCAL\PROGRAMS\PATHEPHONE-DESKTOP\RESOURCES/GO-IPFS/IPFS.EXE DAEMON --ENABLE-PUBSUB-EXPERIMENT ERROR: SERVEHTTPGATEWAY: MANET.LISTEN(/IP4/127.0.0.1/TCP/8080) FAILED: LISTEN TCP4 127.0.0.1:8080: BIND: ONLY ONE USAGE OF EACH SOCKET ADDRESS (PROTOCOL/NETWORK ADDRESS/PORT) IS NORMALLY PERMITTED.

Задумка интересная, этакий popcorn-time для музыки, которого очень не хватает.

Не хватает какой-либо индикации работы, трафик, число нод в сети — чтоб понять вообще что там происходит под капотом.

Судя по ошибке порт 8080 уже занят.

Проверить работает или нет можно запустив две копии приложения на разных устройствах и расшарить на одной из них альбом (обнаружение может занимать от минуты до получаса, может не найти вообще). Наличие контента в сети напрямую зависит от наличия участников.

Панель с индикаторами в планах есть.
Приложение должно называться не патефон, а спатефон)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории