LINUX.ORG.RU

Ответ на: комментарий от Anon

А cmus пробовал? Если нужен консольный вариант, то он почти идеал. В нем есть куча удобных фишек, что нет в говядине. С плейлистами только не так удобно.

another ★★★★★ ()
Ответ на: комментарий от waker

кого пугает? мне он просто не нужен.

Почему?

зачем исключать одно ради другого?

Ну да, необоснованно таскать с собой, конечно, лучше.

они используют ffmpeg так же как ddb. для всякой экзотики. там где есть gapless - нету ffmpeg. другие пруфы будут?

Что такое gapless? Ты уж потрудись тогда объяснить, что ты вкладываешь в это понятие.

FLAC__stream_decoder_seek_absolute

av_seek_frame? Впрочем, зачем оно, например, для wma? Неужели какой-то идиот будет использовать его вместе с cue?

anonymous ()

Вопросы к автору

Я очень давно не щупал DeadBeef, поэтому спрошу тут. Заранее спасибо за ответы.

1. DeadBeef умеет рейтинг (если да, то на сколько позиций) и пользовательские метки для композиций? Если умеет, то сохраняет ли это в файлах или в единой базе?

2. Поддерживает ли он кастомизацию интерфейса (добавление/удаление элементов и их произвольное расположение)? Ну и табы с плейлистов убрать, оставить один, например.

3. Умеет ли он массово изменять теги?

4. Умеет ли «умные» плей-листы? С несколькими параметрами, разумеется. Например, плейлист с треками 2010 года, которые проигрывались менее 10 раз и с рейтингом выше 4 звезд?

5. Поддерживается ли автоматическая или ручная загрузка альбом-арта (album cover) с интернета?

6. (смешной вопрос, но все же) Умеет ли записывать несколько жанров и исполнителей для одной и той же композиции?

neocrust ★★★★★ ()
Ответ на: комментарий от anonymous

Почему?

иди проспись. для ненужности причины не нужны.

Что такое gapless? Ты уж потрудись тогда объяснить, что ты вкладываешь в это понятие.

http://en.wikipedia.org/wiki/Gapless_playback

av_seek_frame? Впрочем, зачем оно, например, для wma? Неужели какой-то идиот будет использовать его вместе с cue?

av_seek_frame делает совсем другое.

waker ★★★★★ ()
Ответ на: комментарий от waker

иди проспись. для ненужности причины не нужны.

Хорошо, а в чём нужность LGPLv2, что ради неё столько секаса?

http://en.wikipedia.org/wiki/Gapless_playback

Вопрос не снят. Зачем для этого нужен точный поиск? Играй всё подряд и не парься.

av_seek_frame делает совсем другое.

Ты уверен? Вижу, что нет. И как там на счёт wma? Ему-то accurate seeking нафиг сдался?

anonymous ()

Слушай, а почему ты не хочешь на GPLv3 перелицензировать?

Anon ()
Ответ на: комментарий от waker

gpl3 код нельзя использовать в gpl2 проектах, не меняя лицензию всего проекта на gpl3 при дистрибуции.

Я имел в виду, что же случится плохого, если поменять лицензию на GPLv3. Но тут, по-видимому, дело во фломастерах, которые на вкус и цвет все разные.

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

Я имел в виду, что же случится плохого, если поменять лицензию на GPLv3. Но тут, по-видимому, дело во фломастерах, которые на вкус и цвет все разные.

Так речь идёт про линковку GPLv2 с LGPLv3. Ничего менять для этого не надо. Но, как видно, герою нашего тоепика проще строить из себя идиота, чем отвечать на этот простой вопрос.

anonymous ()
Ответ на: комментарий от anonymous

Так речь идёт про линковку GPLv2 с LGPLv3. Ничего менять для этого не надо.

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

Теперь про линковку. А ведь патч могут и не принять, заявив, что это расходится с идеологией. Или тебе может понадобиться залезть внутрь. И тут уже линковкой не обойдёшься.

В общем, это не такой простой вопрос, как кажется. Стоит уважать мнение автора проекта. Он никому ничего не обязан, что хочет, то пусть и делает.

i-rinat ★★★★★ ()
Ответ на: комментарий от anonymous

Хорошо, а в чём нужность LGPLv2, что ради неё столько секаса?

я уже отвечал на это. [L]GPL2 нужен, чтобы позволить другим проектам, использующим [L]GPL2, линковаться к моему коду.

также, мне просто не нравится GPL3. мне и GPL2 не нравится, но это меньшее зло.

Вопрос не снят. Зачем для этого нужен точный поиск? Играй всё подряд и не парься.

кроме проигрывания, в плеерах обычно есть перемотка. если использовать ffmpeg - невозможно узнать куда он перематывает с точностью до сэмпла, и нельзя перемотать на нужный сэмпл. всегда есть погрешность. в итоге происходит рассинхронизация. все это накладывается на разные особенности форматов, когда нужно пропустить нужное количество сэмплов в начале и конце файла. после рассинхронизации это уже невозможно, и gapless playback не работает. в случае с cue то же самое.

Ты уверен? Вижу, что нет.

я уверен. av_seek_frame делает перемотку на начало фрейма. фрейм в ffmpeg - это не сэмпл, это блок из файла, содержащий множество сэмплов.

И как там на счёт wma? Ему-то accurate seeking нафиг сдался?

я не очень понимаю, почему ты зациклился именно на wma (это одинаково для всех форматов), но вообще это нужно для cue. чтобы между треками в image+cue был gapless playback.

waker ★★★★★ ()
Ответ на: комментарий от anonymous

Так речь идёт про линковку GPLv2 с LGPLv3. Ничего менять для этого не надо.

нет. речь идет о том, что в составе проекта появится плагин (идущий в основном дистрибутиве), который будет лицензироваться под LGPL3.

если перефразировать, речь идет о том, что в плеере появится LGPL3 код.

waker ★★★★★ ()
Ответ на: комментарий от i-rinat

Я имел в виду, что же случится плохого, если поменять лицензию на GPLv3. Но тут, по-видимому, дело во фломастерах, которые на вкус и цвет все разные.

данный проект движется несколько в другую сторону. недавно основная часть кода была перелицензирована под ZLIB.

в данной ситуации, переход на GPL3 был бы более чем странным.

waker ★★★★★ ()
Ответ на: комментарий от i-rinat

Проблема с внешними библиотеками состоит в том, что они внешние. Если ты находишь там баг, то приходится ждать, пока апстрим починит самостоятельно или примет патч, потом ждать, пока исправленная версия появится в дистрибутиве.

Может тогда и дистрибутив собирать специально под плеер. А то мало ли в ядре чего сломали, не понятно, сколько ждать.

anonymous ()
Ответ на: комментарий от anonymous

Тебя привязали к стулу и заставляют пользоваться deadbeef?

В какой-то момент пользователь решает, что раз он пользуется программой, то вправе решать, как поступать автору. Интересно, так случается только с бесплатными программами? Видел похожую ситуацию с бесплатно оказываемыми услугами.

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

с платной проприетарщиной тоже случается. просто разработчики стараются избегать общения с юзерами напрямую. этим пиарщики обычно занимаются.

waker ★★★★★ ()
Ответ на: комментарий от waker

я уже отвечал на это. [L]GPL2 нужен, чтобы позволить другим проектам, использующим [L]GPL2, линковаться к моему коду.

Я не про смену лицензии говорю, а про линковку. Программа под GPLv2/BSD/*любая коммерческая* спокойно линкуется с библиотекой под LGPLv3. И не надо вводить тут людей в заблуждение.

кроме проигрывания, в плеерах обычно есть перемотка. если использовать ffmpeg - невозможно узнать куда он перематывает с точностью до сэмпла, и нельзя перемотать на нужный сэмпл. всегда есть погрешность. в итоге происходит рассинхронизация. все это накладывается на разные особенности форматов, когда нужно пропустить нужное количество сэмплов в начале и конце файла. после рассинхронизации это уже невозможно, и gapless playback не работает. в случае с cue то же самое.

Перемотка, как минимум, с точностью до секунды обеспечивается практически любой библиотекой. Для форматов wma и прочих пережитков прошлого это более чем достаточно. Кроме того, из твоего поста не понятно, каким образом перемотка связанна с этим твоим gapless? Только по ушам новичкам ездить, если только. Для cue, кстати, тоже не нужно. Файл один, так что бери и играй его до конца.

я уверен. av_seek_frame делает перемотку на начало фрейма. фрейм в ffmpeg - это не сэмпл, это блок из файла, содержащий множество сэмплов.

Т.е. asf_seek по-твоему прыгает на сэмпл? Мда. А зачем тогда миллисекунды передаёшь? Сколько там в одной миллисекунде сэмплов?

я не очень понимаю, почему ты зациклился именно на wma (это одинаково для всех форматов), но вообще это нужно для cue. чтобы между треками в image+cue был gapless playback.

И я о том. Зачем пытаться прыгать в конце каждого трека, когда можно просто проиграть один файл до конца? Прикинь, даже seek дёргать не потребуется.

anonymous ()
Ответ на: комментарий от i-rinat

Тебя привязали к стулу и заставляют пользоваться deadbeef?

Нет, просто я болезненно отношусь к заведомо ложной информации. Это моя слабость, да.

anonymous ()
Ответ на: комментарий от anonymous

Нет, просто я болезненно отношусь к заведомо ложной информации. Это моя слабость, да.

Если ложную информацию выдал я, приведи цитату, пожалуйста. Я хочу знать в чём я заблуждаюсь.

i-rinat ★★★★★ ()
Ответ на: комментарий от anonymous

Зачем пытаться прыгать в конце каждого трека, когда можно просто проиграть один файл до конца? Прикинь, даже seek дёргать не потребуется.

Если бы я делал плеер с поддержкой cue, я бы ввёл абстракцию над cue, которая отдавала плееру отдельные песни, ведь порядок воспроизведения может быть любой. Вместе с тем мне бы не хотелось слушать щелчки между песнями, если я заказал последовательное воспроизведение. Реализация твоей идеи возможно даже даст меньшее использование CPU, но значительно усложнит реализацию, потому что код станет более запутанным.

Если ты действительно веришь в корректность своей идеи, реализуй её, оформи в виде патча и отошли автору. С ссылкой на реализацию твои слова будут более значимы.

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

Нет, он просто знает как правильно делать. Сейчас мы все внимательно послушаем, и будем делать как анонимус сказал.

thesame ★★★★ ()
Последнее исправление: thesame (всего исправлений: 1)
Ответ на: комментарий от Anon

А я бы не делал поддержку cue, т.к. это ненужная фича.

Знаешь, сколько людей так скажут про ИК-спектроскопию? :)

i-rinat ★★★★★ ()
Ответ на: комментарий от anonymous

Я не про смену лицензии говорю, а про линковку. Программа под GPLv2/BSD/*любая коммерческая* спокойно линкуется с библиотекой под LGPLv3. И не надо вводить тут людей в заблуждение.

спасибо что просветил.

Перемотка, как минимум, с точностью до секунды обеспечивается практически любой библиотекой. Для форматов wma и прочих пережитков прошлого это более чем достаточно. Кроме того, из твоего поста не понятно, каким образом перемотка связанна с этим твоим gapless?

перечитай еще раз то на что отвечал. там подробно все написано.

Т.е. asf_seek по-твоему прыгает на сэмпл?

нет. тоже на фрейм. но я знаю на какой сэмпл он прыгает, и корректирую рассинхронизацию. через public api ffmpeg эта информация недоступна.

Мда. А зачем тогда миллисекунды передаёшь? Сколько там в одной миллисекунде сэмплов?

в одной миллисекунде samplerate/1000 сэмплов.

например, при samplerate 44100, в одной миллисекунде 44.1 сэмплов ровно. а при 22050 — 22.05 сэмплов.

waker ★★★★★ ()
Ответ на: комментарий от i-rinat

Если ложную информацию выдал я, приведи цитату, пожалуйста. Я хочу знать в чём я заблуждаюсь.

Твои соображения противоречат понятию дистрибутива линукс в частности и культуре программирования в общем. Ты хоть сам представляешь, что будет,если каждый текстовый редактор и плеер будет таскать с собой пачки библиотек, да ещё с кучей модификаций. Гораздо проще пропатчить кривой ffmpeg, чем рыскать по репам и исправлять ошибки в каждом велосипеде.

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

anonymous ()
Ответ на: комментарий от anonymous

Ты хоть сам представляешь, что будет,если каждый текстовый редактор и плеер будет таскать с собой пачки библиотек, да ещё с кучей модификаций.

будет то же самое, что есть в макоси и венде (а также андроиде, ios, и вообще всех осях кроме линуксов и *bsd). т.е., по сути, ничего особо страшного.

Гораздо проще пропатчить кривой ffmpeg, чем рыскать по репам и исправлять ошибки в каждом велосипеде.

то-то vlc и mplayer таскают свой ffmpeg, да? и наверное не только они. сначала сделай так чтобы девелоперы ffmpeg не ломали API в каждой минорщине.

Кроме того, в сабжевом случае я считаю поставку большего числа библиотек необоснованной.

nobody cares.

waker ★★★★★ ()
Последнее исправление: waker (всего исправлений: 1)
Ответ на: комментарий от anonymous

противоречат понятию дистрибутива линукс в частности

тут ты прав конечно. но какое отношение мой проект имеет к дистрибутиву линукс?

и культуре программирования в общем

а вот это ты выдумал.

waker ★★★★★ ()
Ответ на: комментарий от waker

спасибо что просветил.

И что на этот раз мешает выкинуть старый wildmidi и заюзать ванильный?

перечитай еще раз то на что отвечал. там подробно все написано.

Начинается. Там не обоснована необходимость точности перемотки для всяких «экзотически» форматов внутри ffmpeg, кроме какой-то «рассинхронизации». Чего с чем рассинхронизации? Непонятно. Впрочем, для использования вместе с cue она тоже не обоснована.

нет. тоже на фрейм. но я знаю на какой сэмпл он прыгает, и корректирую рассинхронизацию. через public api ffmpeg эта информация недоступна.

Как ты можешь знать фрейм, если передаёшь миллисекунды? У тебя погрешность уже 22.05 сэмпла просто так.

через public api ffmpeg эта информация недоступна.

Точно?

например, при samplerate 44100, в одной миллисекунде 44.1 сэмплов ровно. а при 22050 — 22.05 сэмплов.

А во фрейме сколько сэмплов?

anonymous ()
Ответ на: комментарий от waker

будет то же самое, что есть в макоси и венде (а также андроиде, ios, и вообще всех осях кроме линуксов и *bsd). т.е., по сути, ничего особо страшного.

Это даже не смешно. Там катастрофа вообще-то.

то-то vlc и mplayer таскают свой ffmpeg, да? и наверное не только они. сначала сделай так чтобы девелоперы ffmpeg не ломали API в каждой минорщине.

А пруф будет, где они там чего сломали в минорщине?

nobody cares.

Ну это и понятно, когда аргументация хромает.

anonymous ()
Ответ на: комментарий от waker

тут ты прав конечно. но какое отношение мой проект имеет к дистрибутиву линукс?

Отмазывайся давай.

а вот это ты выдумал.

Обоснуй.

anonymous ()
Ответ на: комментарий от anonymous

И что на этот раз мешает выкинуть старый wildmidi и заюзать ванильный?

то же что и раньше — нежелание иметь [l]gpl3 код в тарболе.

насчет ванильного wildmidi я не уверен. не факт, что там исправили все баги.

Там не обоснована необходимость точности перемотки для всяких «экзотически» форматов внутри ffmpeg

такой необходимости нет. для форматов, которые играют через ffmpeg, не поддерживается gapless.

Непонятно. Впрочем, для использования вместе с cue она тоже не обоснована.

после изучения матчасти все должно встать на свои места.

Как ты можешь знать фрейм, если передаёшь миллисекунды? У тебя погрешность уже 22.05 сэмпла просто так.

да, извини, я совсем забыл, что wma плагин не умеет этого. перепутал с каким-то другим. во многих других плагинах сначала делается seek на фрейм, а потом корректировка.

Точно?

да.

А во фрейме сколько сэмплов?

сколько угодно. в случае WMA как раз поэтому и не поддерживается sample accurate seeking. для CBR файлов я смог реализовать, а для VBR не получилось. также, у меня не получилось определить VBR vs CBR. я мог реализовать gapless путем чтения файла сначала целиком при каждом seek, как в случае с sid, но будет очень тормозить. в sid просто вообще другого выбора не было.

waker ★★★★★ ()
Ответ на: комментарий от anonymous

Обоснуй.

ты выдумал - ты и обосновывай.

waker ★★★★★ ()
Ответ на: комментарий от anonymous

Это даже не смешно. Там катастрофа вообще-то.

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

А пруф будет, где они там чего сломали в минорщине?

а не много ли ты хочешь? гугл в помощь.

waker ★★★★★ ()
Ответ на: комментарий от anonymous

Твои соображения противоречат понятию дистрибутива линукс в частности и культуре программирования в общем.

К сожалению, эта идея иногда не работает. У меня сейчас в debian есть проблема: я не могу поставить некоторый софт, не удалив другой. Потому что одна программа зависит от 53-й версии, а другая от 54-й. (ffmpeg/libav). А эти версии почему-то вместе не ставятся. Я пользователь и не хочу решать эти проблемы. Я хочу слушать музло и копаться в результатах вывода callgrind. Желательно одновременно.

Гораздо проще пропатчить кривой ffmpeg, чем рыскать по репам и исправлять ошибки в каждом велосипеде.

Ну так это — пропатчи. И сделай так, чтобы апстрим принял, и не ломал потом. Болтать-то легко.

Только это вынужденное решение, а не какой-то плюс.

А я и не говорил, что это плюс. Я говорил, что понимаю это решение. Как и лицензионные проблемы, к которым оно приводит.

Кроме того, в сабжевом случае я считаю поставку большего числа библиотек необоснованной.

К таким заявлениям нужно прикладывать прототип.

i-rinat ★★★★★ ()
Последнее исправление: i-rinat (всего исправлений: 1)
Ответ на: комментарий от anonymous

Ну это и понятно, когда аргументация хромает.

с аргументацией все в порядке. просто каждому анонимусу аргументировать — аргументилка сломается. я даж подозреваю, что ты тот же самый анонимус, который меня достал в прошлый раз, с такими же идиотскими вопросами.

waker ★★★★★ ()
Ответ на: комментарий от stels

ну вначале это было даже весело. просто надоело уже :)

waker ★★★★★ ()
Ответ на: комментарий от waker

то же что и раньше — нежелание иметь [l]gpl3 код в тарболе.

Опять 25. Линковка динамическая. lgplv3 - внешняя библиотека. Кто тебя заставляет делать плагин под gplv3?

такой необходимости нет. для форматов, которые играют через ffmpeg, не поддерживается gapless.

Так gapless или accurate seeking? Это разные вещи вообще-то.

после изучения матчасти все должно встать на свои места.

Таки нет. Загоняю ape в ffplay и наслаждаюсь всем диском целиком. ЧЯДНТ?

да.

Про пруф я уже не смею спрашивать.

сколько угодно. в случае WMA как раз поэтому и не поддерживается sample accurate seeking. для CBR файлов я смог реализовать, а для VBR не получилось. также, у меня не получилось определить VBR vs CBR. я мог реализовать gapless путем чтения файла сначала целиком при каждом seek, как в случае с sid, но будет очень тормозить. в sid просто вообще другого выбора не было.

Какой sample ассurate, если ты миллисекунды передаёшь?

anonymous ()
Ответ на: комментарий от waker

с аргументацией все в порядке. просто каждому анонимусу аргументировать — аргументилка сломается. я даж подозреваю, что ты тот же самый анонимус, который меня достал в прошлый раз, с такими же идиотскими вопросами.

Ну начинается. Ты ответь нормально, а уж там посмотрим. Я человек, жаждущий докопаться до истины. А у тебя пока что враньё сплошное и какие подростковые понты. Зачем нужен sample accurate для wma, я тоже так и не понял. Хотя тут точнее говорить про time accurate тогда уж. Зачем путать и подменять понятия, я тоже не понимаю. И зачем он нужен для gapless тоже ты так и не объяснил.

anonymous ()
Ответ на: комментарий от anonymous

Опять 25. Линковка динамическая. lgplv3 - внешняя библиотека. Кто тебя заставляет делать плагин под gplv3?

по-умолчанию подразумевается, что это будет статическая линковка, т.к. (за недоказанностью обратного) библиотеку придется допиливать.

Так gapless или accurate seeking? Это разные вещи вообще-то.

1е не работает без 2го.

Таки нет. Загоняю ape в ffplay и наслаждаюсь всем диском целиком. ЧЯДНТ?

ffplay не разбивает файл на треки, в нем это 1 трек.

в deadbeef image+cue это несколько треков в плейлисте, работа с которыми производится как с отдельными файлами. их можно конвертировать, например, в отдельные треки в FLAC, без потери точности в позиционировании, можно смотреть per-track metadata, производить поиск, отдельные обложки на каждый трек, и прочее.

Какой sample ассurate, если ты миллисекунды передаёшь?

в случае с WMA да. в других форматах другая ситуация. везде все индивидуально.

waker ★★★★★ ()
Ответ на: комментарий от anonymous

Зачем нужен sample accurate для wma, я тоже так и не понял.

он нужен, чтобы проигрывать wma image+cue без дырок между треками. но его в любом случае нет, так что и вопрос лишен смысла.

И зачем он нужен для gapless тоже ты так и не объяснил.

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

waker ★★★★★ ()
Ответ на: комментарий от Anon

Есть для qt сторонний плагин, правда не развивается, емнип.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.