Вопрос по обновленной МУЗ БАЗЕ

[scorp]

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

- Ну вот, не знаете, а говорите
Напрасно Вы так ругаетесь. Там ведь далеко не дураки работают... Доп.файлы занимают считанные килобайты и никого абсолютно не стесняют. Но выполняют очень важную роль, которую выше я уже описал.
В проводнике программы скрыть файлы с определенным (не "музыкальным") расширением - пустяк вообще.
Так чем вам мешают дополнительные файлы с данными о треке? Есть многолетняя практика работы с таким методом. Почему бы не перенять положительный опыт..?

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

Более удобного чем база, особенно SQLite для таких целей и придумать сложно. И никаких заморочек с доп.файлами. Кроме того, кто эти файлы сможет прочитать, какие программы знают про них, что в них там надо искать метки и прочее... Это ж метки РБ, и с тегами удобнее работать через базу... Вообще через базу масса удобств. Надо только еще сделать доступ к базе полноценный через АПИ и можно будет чудить...

 

[Ian]

Мне вообще непонятен сей посыл!

Новосёл, могу ли я вас попросить хотя бы временно отключиться от данной ветки форума и не засорять общение вашими совершенно не относящимся к теме работы БД пустыми рассуждениями и домыслами?
Ваше мнение все поняли.

 

[Ian]

Это какая-то другая проблема. Может быть, тег изначально был поврежден, и после добавления/удаления APEv2 все стало совсем плохо. Поэтому для FLAC и WAV тег APEv2 больше не пишется.

Дмитрий, честно?
Я впервые встречаю проблемы с работой над файлами FLAC именно в программе RadioBoss.
Больше нигде таких проблем нет.
Кстати работа с пользовательскими тегами -- ту даже.

Вот цитата из форума Foobar2000:

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

А вот цитата после отосланного мной "битого файла". Дмитрий. В ваш, извините, огород камешек:

Кому-то в голову пришла "светлая" мысль писать в файл в формате FLAC теги сразу в 2-ух непредусмотренных стандартом форматах: в ID3 и в APE. Это полная лажа. В данном случае часть тегов в ID3 фубар всё-таки видит, а APE вообще не воспринимает.
Разработчики программы, которая так пишет теги - чудаки на букву "М". Дайте им ссылку на спецификацию флака, пусть просвящаются - https://xiph.org/flac/format.html

 

[Ian]

В смысле 3 часа? Где? Я тестирую до сих пор. Если бы я тестировал 3 часа то так и было бы... то там через месяц косяк, то там нежданчик..

Повторюсь. Я писал о проблеме.

 

[Ian]

И самый главный вопрос, на который я не получил ответ:

Вводите работу с БД, но зачем стирать метаданные из файлов?
Кто просил вас эту опцию внедрять?​

И главное -- об этом полнейшая тишина. Хоть бы предупредили, что "Ребята, в новой версии, при конвертации, в ваших файлах, кто использует эту опцию (кроме самого умного Новосёла, с радиостанции "Толстушка", разумеется) будет стёрта доп.информация с разметками, будьте осторожны!"

 

[djsoft]

Действительно, посмотрите в эту сторону. Это очень простой и надёжный способ хранить информацию о файлах и делиться ею между разными компьютерами. И не нужно никаких БД.

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

Но если так и вздумается кому-то делать, то только опционально.

Конечно опционально. Тег был и есть способ по умолчанию. База и если что-нибудь еще добавим - для специальных ситуаций.

Так чем вам мешают дополнительные файлы с данными о треке? Есть многолетняя практика работы с таким методом. Почему бы не перенять положительный опыт..?

RadioBOSS создается с другой концепцией, нередео противоположной тому, что принято в большинстве других программ для автоматизации радио. В некоторых других программах добавление трека это целая операция, заполнение каких-то "карточек треков", "импорт трека в базу", а нередко даже сама установка программы - целая эпопея с настройками баз данных, паролей, связка модулей и черт знает что. Поэтому перед тем, как что-то "перенять" нужно очень крепко подумать... То же добавление простейшей локальной базы, кажется, принесло больше проблем, чем решило.

 

[djsoft]

Я впервые встречаю проблемы с работой над файлами FLAC именно в программе RadioBoss.
Больше нигде таких проблем нет.
Кстати работа с пользовательскими тегами -- ту даже.

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

Кстати работа с пользовательскими тегами -- ту даже.

А что не так с пользовательскими тегами?

Вводите работу с БД, но зачем стирать метаданные из файлов?

Ничего не стирается. Если для FLAC встречается тег APEv2, записанный предыдущими версиями программы - он прочитывается, эта информация пишется в альтернативный поток, и затем тег удаляется. Доп. информация при этом остается и никуда не девается.

Вот это

Хоть бы предупредили, что "Ребята, в новой версии, при конвертации ... будет стёрта доп.информация с разметками, будьте осторожны!"

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

 

[Novossyol]

не засорять общение вашими совершенно не относящимся к теме работы БД пустыми рассуждениями и домыслами?

А вот вы и объясните каков практический смысл, для чего вообще в тэгах какие-то метки и пр." рюшечки"? Разве без этого нельзя обойтись другими методами? А то тут скоро с десяток страниц нафлудим и к консенсусу не придем.
Мне это напоминает рассуждения на тему "сколько пикселей в фотографии, может ещё один пиксель добавим"? 

(кроме самого умного Новосёла, с радиостанции "Толстушка", разумеется)

Хорошо смеётся тот, кто смеётся последним.  ;D
Сравним ваш и мой эфир и я на 100500% уверен, что сторонний радиослушатель не найдет даже 3 отличий. Когда коту делать нечего...

 

[an-kov]

Новосел, а где можно услышать в сети вашу станцию, очень интересно? Предвидя ответ-нигде, готов предоставить Вам БЕСПЛАТНО ресурсы своего icecast сервера в любом качестве битрейта.

 

[scorp]

Новосел, а где можно услышать в сети вашу станцию, очень интересно? Предвидя ответ-нигде, готов предоставить Вам БЕСПЛАТНО ресурсы своего icecast сервера в любом качестве битрейта.

Он играется судя по всему с Шоуткастом у себя на ПК )))

 

[djsoft]

А вот вы и объясните каков практический смысл, для чего вообще в тэгах какие-то метки и пр." рюшечки"?

Метки используются для войсдропов, нарезок, для установки начала-конца трека (например, отрезать очень длинную инструментальную часть), для задания индивидуальных параметров микса и множество других параметров. Также, там сохраняется количество запусков трека и дата-время последнего запуска.

 

[Максим.Осадчи]

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

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

В случае, если мне нужно "поделиться" треками с удалённым компьютером - я закидываю нужные файлы, например, в плейлист плеера AIMP, а из него уже сохраняю эти треки в нужный мне каталог, сохраняя при этом точную иерархию каталогов и копирую вместе с аудиотреками файлы  с такими же именами, но с расширениями, которые я укажу. Всё.

Треки скопированы вместе со всей информацией о них. Всё просто до безобразия и главное - эффективно.

И никаких проблем с "раскладыванием файлов"...

 

[Novossyol]

Он играется судя по всему с Шоуткастом у себя на ПК )))

Всё свое ношу с собой. Канала в 100 мбит хватит на всех и ещё останется.)))
Вещание нерегулярное. Технические работы и отладка оборудования.
Сейчас вот думаю сайт переносить на свой домашний комп, так как не имеет экономического и практического смысла его держать на хостинге.

Метки используются для войсдропов, нарезок

А что разве стандартного кроссфейда не хватает для большинства случаев?

(например, отрезать очень длинную инструментальную часть)

Я это делаю сразу в редакторе при подготовке трека в музбазу. Нормализую трек, отрезаю тишину в начале и конце трека и сохраняю в mp3 320/44100.

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

В каком % случаев это очень необходимо и просто незаменимо?

Также, там сохраняется количество запусков трека и дата-время последнего запуска.

Это мы знаем, для того пока и оставляем тэг в треке, ни для чего более.

 

[scorp]

Я это делаю сразу в редакторе при подготовке трека в музбазу. Нормализую трек, отрезаю тишину в начале и конце трека и сохраняю в mp3 320/44100.

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

 

[avg]

Я это делаю сразу в редакторе при подготовке трека в музбазу. Нормализую трек, отрезаю тишину в начале и конце трека и сохраняю в mp3 320/44100.

То есть, даже если трек до этого был, допустим 128/44100, Вы его потом сохраняете в 320/44100 ?

 

[avg]

Здесь это не воспроизводится. Для mp3 проставляются метки, все сохраняется в тегах. Файл копируется на другой компьютер, добавляется в базу, конвертация из тега в базу - в Track Tool все метки есть.
Убедитесь, что выбрано правильное направление конвертации, и что после конвертации обработано правильное количество файлов (N files processed) - должно совпадать с количеством выделенных треков в окне базы, для которых делалась конвертация.

Извиняюсь за дачу ложных показаний 
Направление конвертации выбирал правильное, после конвертации, так же показывало (28 files processed), так как 28 файлов и конвертировал.
Пробовал и обратную конвертацию из SQLite в APEv2, и так же ничего не происходило, то есть при просмотре файла тегов APEv2 через Mp3tag и в файле ничего не менялось, то есть данные оставались старыми.
Попробовал сегодня, все метки начали сохраняться, мистика.
Еще раз извиняюсь.

 

[Novossyol]

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

Однако как вы проводите нормализацию уровня, если трек тихий? Я же все треки в редакторе нормализую под 0 дБ, но "без зашкала".
Да ради бога, я тоже не пересжимаю, просто разворачиваю его в редакторе из mp3 в РСМ, а потом сохраняю с бОльшим битрейтом. Качество не страдает, так как контейнер 320 кбит с бОльшей пропускной способностью, чем первоисточник либо равный ему и не спорить. Сверялся с оригиналом никаких изменений по звуку - ничто, ничего и никуда не теряется, во всяком случае в диапазоне 30-15000 гц, что было то и осталось! А вы верьте мифам "аудиофилов" и играйтесь себе дальше с базой и тэгами. )))

То есть, даже если трек до этого был, допустим 128/44100, Вы его потом сохраняете в 320/44100 ?

Да, а что здесь удивительного? Я для себя всё привожу к одному вещательному стандарту - не люблю разношёрстность.
Но треки в 128 кбит я стараюсь не брать в работу вообще, только ввиду крайней необходимости, когда трек ну уж "очень эксклюзивный" и его не найти в 320 кбит.

 

[avg]

Однако как вы проводите нормализацию уровня, если трек тихий? Я же все треки в редакторе нормализую под 0 дБ, но "без зашкала".

Это похвально, что Вы перед добавлением трека в базу, проводите нормализацию, но извольте, что за аудио процессор используете, AGC и клипер с этим справиться на ура, все будет звучать на одном уровне.

Да, а что здесь удивительного? Я для себя всё привожу к одному вещательному стандарту - не люблю разношёрстность.

А в чем собственно разношерстность, в циффарках ?
То, что не берете файлы меньшего битрейта, это так же хорошо, но вот только, было бы неплохо посмотреть так же спектрограмму файла, так как файл сконвертированный из 128 в 320, даже предварительно нормализовав его, картина получается следующая, смотрим картинку.
А вот размер файла увеличился с 3.73 MB в 9.32 MB

 

[Novossyol]

но извольте, что за аудио процессор используете, AGC и клипер с этим справиться на ура, все будет звучать на одном уровне.

Не будет. Не вытягивает Стереотул. У вас может и вытягивает.

А вот размер файла увеличился с 3.73 MB в 9.32 MB

При нынешних объёмах HDD проблема неактуальна. Я с 2010 года даже 1 ТБ HDD не менял на больший. )))

 

[scorp]

Однако как вы проводите нормализацию уровня, если трек тихий? Я же все треки в редакторе нормализую под 0 дБ, но "без зашкала".
Это похвально, что Вы перед добавлением трека в базу, проводите нормализацию, но извольте, что за аудио процессор используете, AGC и клипер с этим справиться на ура, все будет звучать на одном уровне.

Вот-вот, я к примеру включил AutpAmp в РБ + поставил Stereo Tools и вообще бомба, плюс там и спектр немного можно скорректировать если урезан... на слуха становиться заметно приятнее.. и не надо заниматься ерундой типа нормализаций и прочего... все на лету..