Войсдропы

djsoft сказал(а):
Это является очень специфичной проблемой.
Эта проблема "специфична" для всех тех, кто вещает "пиратский" контент и не заключает договоров и соглашений. Получение таких документов -- это сложная и напряжённая работа. На эту работу мы потратили больше 5 лет!  В них у нас прописаны файлы, источники получения и разрешения. В таких документах, где мы фиксируем наименование файлов, должны совпадать абсолютно все знаки. Многие договоры мы либо не сможем перезаключить, либо не готовы выкладывать за это несколько сотен тыс. рублей.

djsoft сказал(а):
Он не меняется без причины, для MP3 и всех других форматов (кроме FLAC и WAV) никаких изменений уже полтора десятка лет - нет.
Мы до сих пор не можем понять, почему в последней версии RadioBoss 5.5.5.0 файлы FLAC отрабатываются хорошо, а начиная со следующей версии, вдруг потребовалось изменить подход хранения мета-дат. Изменения, которые коснулись нас были внедрены без предупреждения. Сам этот процесс вы также не отработали и не протестировали. Проблему вскрыли мы. Почему нужно было столь кардинально изменять принцип хранения мета-дат, мы понять не можем.
Повторимся: Всё работало прекрасно! Что мешает вернуть отработку FLACа в новые версии?
 
Ian сказал(а):
Эта проблема "специфична" для всех тех
Ваш случай специфичный, даже уникальный, больше никто с такой проблемой не обращался. База SQLite не подходит, потоки NTFS не подходят, файлы нельзя конвертировать. Есть три разных варианта решения задачи, но вам ни один не подходит. К сожалению, что-то обещать с нашей стороны я не могу, разработка таких "специфичных" решений дело не приоритетное.

Ian сказал(а):
Мы до сих пор не можем понять, почему в последней версии RadioBoss 5.5.5.0 файлы FLAC отрабатываются хорошо
Так там не хорошо было. В файл прописывался тег APEv2, а по стандарту формата FLAC так делать нельзя. Это могло, и иногда приводило, к тому, что файл переставал запускаться или играл не до конца. Поэтому от тега APEv2 для формата FLAC отказались, и теперь данные (по умолчанию) хранятся в потоках NTFS - так делается только для FLAC и WAV.

Ian сказал(а):
Сам этот процесс вы также не отработали и не протестировали.
Процес оттестирован и работает. Но не при любых условиях - любая технология имеет ограничения. Просто для вашего случая такое решение не подошло. А ввиду прочих ограничений (весьма специфичных) - получилось, что ничего толком не подходит.

Ian сказал(а):
В таких документах, где мы фиксируем наименование файлов, должны совпадать абсолютно все знаки.
Проблема у вас бюрократическая, а не техническая. Я предлагаю самое технически адеватное решение - использовать формат APE. Он также, как и FLAC - lossless, т.е. аудио содержимое треков не изменится при изменении формата. Теги тоже останутся как есть.
 
djsoft сказал(а):
База SQLite не подходит, потоки NTFS не подходят, файлы нельзя конвертировать.
Кто вам такие глупости сказал?
- Если вы, Дмитрий, помните, мы были За создание базы. Но если бы вы написали ещё на стадии создания её что "Базу мы создадим, но именно в файлах FLAC храниться данные больше не будут", то мы бы сразу поняли бы, что нас ждёт и были бы категорически против этого безобразия!
- NTFS-потоки нам не подходят, потому что это не подходит для хранения и переноса данных. Собственно, из этой проблемы вырастает другая -- конвертация всего массива файлов. Это не нужно делать, если решится проблема с NTFS. Как мы уже писали, наш юрист запретил нам конвертировать файлы.

djsoft сказал(а):
К сожалению, что-то обещать с нашей стороны я не могу
А ведь обещали.

djsoft сказал(а):
Так там не хорошо было. В файл прописывался тег APEv2, а по стандарту формата FLAC так делать нельзя. Это могло, и иногда приводило, к тому, что файл переставал запускаться или играл не до конца.
Об этой проблеме вы также узнали от нас, но мы с ней научились бороться и она не досаждала нам так сильно.

djsoft сказал(а):
Поэтому от тега APEv2 для формата FLAC отказались
...поэтому с нами нужно было посоветоваться. Обсудить проблему на форуме и сделать так, чтобы клиент остался доволен. Пока что мы не только не довольны, мы возмущены!

djsoft сказал(а):
А ввиду прочих ограничений (весьма специфичных) ...
Опять -- двадцать пять. Вы, как мантру повторяете эту глупость!
Отвечаем:
С каких это пор FLAC является "специфичным ограничением"?
Может вам нужно было просто прочесть документацию? Вам ссылку на неё дать?

djsoft сказал(а):
получилось, что ничего толком не подходит.
... получилось, что вы сделали на "итак сойдёт".

djsoft сказал(а):
Проблема у вас бюрократическая, а не техническая.
Авторские права, Дмитрий -- это, откроем вам прописную истину -- одна большая бюрократия. Мы бы с большим удовольствием работали бы так, как, скажем Новосёл с этой его станцией "Толстушка".
Но мы люди приличные, честные и хотим, чтобы все работали так же.
Знаете, вашу программу мы ведь тоже могли бы скачать бесплатно, но мы изначально выбрали честную работу.

djsoft сказал(а):
Я предлагаю самое технически адеватное решение - использовать формат APE. Он также, как и FLAC - lossless, т.е. аудио содержимое треков не изменится при изменении формата. Теги тоже останутся как есть.
Спасибо за ваше предложение. Оно обойдётся нам в какое-то количество человеко-часов и несколько сотен тыс. рублей. Также нам нужно заново проставить все метки на треках и заполнить пр. теги, поскольку при конвертации они теряются. Также нам нужно перезаключить договоры с рядом издательств и агрегаторов. Это называется "подруга подкинула проблем ..."
 
Ian сказал(а):
Кто вам такие глупости сказал?
Так вы же и сказали, что вам по разным причинам ничего не подходит.

Ian сказал(а):
Но если бы вы написали ещё на стадии создания её что "Базу мы создадим, но именно в файлах FLAC храниться данные больше не будут"
Если у вас способ хранения доп. информации - база, то для всех треков, включая FLAC, данные будут в базе. В случае с базой различий между форматами нет. Но запись в базе привязана к файлу по полному имени файла. База локальная, если нужно переносить файлы на другой компьютер, то база не подходит.

Ian сказал(а):
NTFS-потоки нам не подходят, потому что это не подходит для хранения и переноса данных.
Потоки можно перенести на другой компьютер, есть разные способы. Самый простой - упаковать файлы в архив RAR, и потоки будут сохранены.

Ian сказал(а):
С каких это пор FLAC является "специфичным ограничением"?
Не FLAC, а вот это - Как мы уже писали, наш юрист запретил нам конвертировать файлы..

Ian сказал(а):
Авторские права, Дмитрий -- это, откроем вам прописную истину -- одна большая бюрократия.
Конвертация файлов (тем более lossless) авторские права не нарушает. Повторюсь, это какие-то ваши внутренние дела, что вам нельзя файлы конвертировать. Но что мешает использовать FLAC и при переносе файлов на другой компьютер упаковывать их в архив RAR? Неужели архивы, даже в качестве транзитного инструмента, юрист тоже запретил?

Ian сказал(а):
Также нам нужно заново проставить все метки на треках и заполнить пр. теги, поскольку при конвертации они теряются.
Если конвертировать через RadioBOSS 5.6+, то метки не теряются.

Второе технически адекватное решение для вас, если не хочется конвертировать в APE - все оставить как есть, но при переносе на другие компьютеры упаковывать треки в архив RAR. При распаковке треки распакуются вместе с потоками, и метки сохранятся.
 
Ian сказал(а):
Второе технически адекватное решение для вас, если не хочется конвертировать в APE - все оставить как есть, но при переносе на другие компьютеры упаковывать треки в архив RAR. При распаковке треки распакуются вместе с потоками, и метки сохранятся.

Такой вопрос:
Вот мы можем гонять файлы FLAC, с заполненными тегами по Сети, по Интернету и такие файлы после всех этих переносов будут прекрасно читаться абсолютно во всех плеерах, в которых эти самые теги были записаны. Включая обложку, между прочим.

Но!
Но только не в RadioBoss!
В программе RadioBoss, работа с блоками данных в файлах FLAC реализована не корректно. Изначально были проигнорированы предписания спецификаций стандарта.

Разработчики, пожалуйста, ознакомьтесь с документацией (https://xiph.org/flac/format.html#metadata_block) и исправьте эту ошибку.
 
Ian сказал(а):
Вот мы можем гонять файлы FLAC, с заполненными тегами по Сети, по Интернету и такие файлы после всех этих переносов будут прекрасно читаться абсолютно во всех плеерах, в которых эти самые теги были записаны. Включая обложку, между прочим.

Но!
Но только не в RadioBoss!
И в RadioBOSS будут. Обложки, стандартные теги - все хранится в стандартном для FLAC теге, читается и пишется любыми программами, RadioBOSS в том числе. Думаю, обсуждение вашей проблемы уже исчерпало себя - вся информация и варианты решения проблемы даны в предыдущих сообщениях темы.

Ian сказал(а):
наш юрист запретил нам конвертировать файлы.
Эта ситуация создана вашим юристом и прочей бюрократией. А решение вы хотите от нас.
 
djsoft сказал(а):
вся информация и варианты решения проблемы даны в предыдущих сообщениях темы.

То, что вы предлагаете -- это издевательство! Никто не позволит тратить время редакторов на запаковку-распаковку файлов в архивы.

Лучше займитесь исправлением ошибки.
 
djsoft сказал(а):
Эта ситуация создана вашим юристом и прочей бюрократией. А решение вы хотите от нас.

Конечно от вас, это же вы накосячили!
Я файлы, с записанными в программе RadioBoss отправлял программистам, на форум. Ответ их в ваш адрес вы видели. На ошибку они указали.
Нашего юриста оставьте в покое, он делает свою работу и справляется с ней на отлично, в отличие  от вас, кстати.

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

FLAC в программе RadioBoss реализован криво!

Уму непостижимо, как в России работают...
 
Ian сказал(а):
Никто не позволит тратить время редакторов на запаковку-распаковку файлов в архивы.
На фоне количества времени на передачу файлов (насколько я помню, у вас это делается по сети) - запаковка файлов мгновенная операция. Никакой проблемы в этом нет. Пакуйте без сжатия, там есть такая опция - на SSD диске несколько гигабайт пакуются за секунды.

Ian сказал(а):
Лучше займитесь исправлением ошибки.
Нет ошибки. Это детали технической реализации.

Ian сказал(а):
Уму непостижимо, как в России работают...
Чуть менее, чем 100% разработчиков давно закрыли бы такую тему. Никто, если речь идет о коммерческом софте, не обрабатывает частные случаи - напомню, с этой проблемой обратились только вы и никто больше, хотя программа работает в 127 странах(!). Большинство разработчиков в таких случая отвечают что-то вроде
Спасибо за ваше обращение, и спасибо, что пользуетесь нашим продуктом. Мы очень ценим вас как клиента. Рассмотрев ваше обращение по изменению функционала, сообщаем, что наши технические специалисты изучили проблему и пришли к выводу: программа работет корректно, никаких изменений не требуется. Если у вас есть другие вопросы, обращайтесь.

У нас же, изменение для FLAC стоит в очереди на разработку. Хоть и с низким приоритетом.
 
djsoft сказал(а):
Но что мешает использовать FLAC и при переносе файлов на другой компьютер упаковывать их в архив RAR? Неужели архивы, даже в качестве транзитного инструмента, юрист тоже запретил?
Ну вот Дмитрий, а вы говорите, что файловые операции на эфирных машинах никто не делает. Ещё как делают!
Сами же и пропагандируете, притом не просто копирование, а уже и архивирование.  ;)
А копирование вы считаете "сложной" функцией и всячески отговариваете пользоваться ей, что весьма странно....  ???
Ian сказал(а):
Вот мы можем гонять файлы FLAC, с заполненными тегами по Сети, по Интернету и такие файлы после всех этих переносов будут прекрасно читаться абсолютно во всех плеерах, в которых эти самые теги были записаны. Включая обложку, между прочим.
А какой в этом смысл? RB это программа автоматизации эфира, а не дистрибьютерская сеть для раздачи файлов с тэгами, да ещё и с обложками. Кому они нужны, там мусор один...
Ian сказал(а):
Спасибо за ваше предложение. Оно обойдётся нам в какое-то количество человеко-часов и несколько сотен тыс. рублей. Также нам нужно заново проставить все метки на треках и заполнить пр. теги, поскольку при конвертации они теряются. Также нам нужно перезаключить договоры с рядом издательств и агрегаторов. Это называется "подруга подкинула проблем ..."
Если вы такие "крутые", то что здесь делаете на форуме для начинающих и малых вещателей?
В вашем случае есть Синадин, Джин и пр. "штучки федерального уровня" за сотни тыс. руб.
 
Novossyol сказал(а):
А копирование вы считаете "сложной" функцией и всячески отговариваете пользоваться ей, что весьма странно....

Прежде чем писать бред неплохо бы потрудиться и вникнуть в суть темы. А вы просто увидели слово "копировать" или "архивировать" и сразу перекрутили все как вам нравится.
 
Novossyol сказал(а):
А копирование вы считаете "сложной" функцией и всячески отговариваете пользоваться ей, что весьма странно
Где я такое говорил, можно ссылку?
 
djsoft сказал(а):
Где я такое говорил, можно ссылку?
Пожалуйста:
djsoft сказал(а):
Можно без планировщика, используя целую груду программ, копировать файл много раз в разные папки. Потом не забывать вычищать. Но делать так смысла мало, т.к. это автоматизируется программой, сокращая количество работы процентов на 90
Какую груду программ, Дмитрий вы о чем? Нужен всего лишь ОДИН файловый менеджер (он уже у многих стоит давно) и ОДНА "прозрачная" (а не команды, скрипты, макросы) операция копирования в любое кол-во папок назначения, но вы утверждаете, что "это сложно". Я никак иначе не могу понять смысл вашей фразы.
 
Novossyol сказал(а):
Какую груду программ, Дмитрий вы о чем? Нужен всего лишь ОДИН файловый менеджер (он уже у многих стоит давно) и ОДНА "прозрачная" (а не команды, скрипты, макросы) операция копирования в любое кол-во папок назначения, но вы утверждаете, что "это сложно".
Да, это сложно и муторно. Вы забыли еще про удаление роликов - это тоже муторно. И надо вообще не забывать это делать, т.к. все вручную. Зачем все это, если это давным давно делается RadioBOSSом автоматически, мне непонятно. Но дело ваше. Наверное, уже хватит в каждой теме обсуждать это.
 
djsoft сказал(а):
Да, это сложно и муторно. Вы забыли еще про удаление роликов - это тоже муторно.
Доли секунд на обе операции (копирование и удаление) - муторно?!  :eek:
Значит сделаем сотые доли секунд...  ;D
А в принципе какая разница заливать и удалять один файл или сразу несколько, по времени это занимает одинаково.

Браво, Дмитрий, ничего более "значимого" я от вас услышать и не ожидал.
Зато немуторно: писать "скрипты, плавающие переменные, макросы, команды" и прочую "голубую муть"...
djsoft сказал(а):
Зачем все это, если это давным давно делается RadioBOSSом автоматически
В смысле автоматически? А RB что, тоже умеет определять какие файлы нужно скопировать на эфирную машину, извиняюсь не знал, но почему-то мой RB пока что этого не умеет и мнё все равно приходится выбирать и заливать файлы со сторонних источников ручками...  ???
...А если все мы их заливаем ручками, так не проще ли залить СРАЗУ В НУЖНЫЕ МЕСТА (папки). По-моему это здраво и логично.
 
Novossyol сказал(а):
Зато немуторно: писать "скрипты, плавающие переменные, макросы, команды"

Вообще-то переменные и т.п - это неотъемлемый элемент гибкости и особенно там, где речь идет об автоматизации.
 
scorp сказал(а):
Вообще-то переменные и т.п - это неотъемлемый элемент гибкости и особенно там, где речь идет об автоматизации.
Вот же какие все упёртые! Что называется "ты их в дверь - они в окно". Согласиться с прописными истинами видимо религия не позволяет...
Гибкость - это одно, а удобство, простота, а главное наглядность работы - это другое. Не думаю, что переменные, макросы, скрипты создают наглядность работы. При взгляде на эти файлы ты не понимаешь, что он должен сделать - нужно знать синтаксис и прочие команды внутри этих файлов. При взгляде на аудиофайл в нужной папке, сразу понятно, что будет происходить - воспроизведение файла. 100% автоматизации всё равно никогда не будет - будет небольшая доля ручного труда. А все об этом почему-то забывают.
Ещё не убедил?  :P
 
Назад
Верх