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

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

Более удобного чем база, особенно SQLite для таких целей и придумать сложно. И никаких заморочек с доп.файлами. Кроме того, кто эти файлы сможет прочитать, какие программы знают про них, что в них там надо искать метки и прочее... Это ж метки РБ, и с тегами удобнее работать через базу... Вообще через базу масса удобств. Надо только еще сделать доступ к базе полноценный через АПИ и можно будет чудить...
 
Novossyol сказал(а):
Мне вообще непонятен сей посыл!
Новосёл, могу ли я вас попросить хотя бы временно отключиться от данной ветки форума и не засорять общение вашими совершенно не относящимся к теме работы БД пустыми рассуждениями и домыслами?
Ваше мнение все поняли.
 
djsoft сказал(а):
Это какая-то другая проблема. Может быть, тег изначально был поврежден, и после добавления/удаления APEv2 все стало совсем плохо. Поэтому для FLAC и WAV тег APEv2 больше не пишется.
Дмитрий, честно?
Я впервые встречаю проблемы с работой над файлами FLAC именно в программе RadioBoss.
Больше нигде таких проблем нет.
Кстати работа с пользовательскими тегами -- ту даже.

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

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

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

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

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

Максим Осадчий сказал(а):
Так чем вам мешают дополнительные файлы с данными о треке? Есть многолетняя практика работы с таким методом. Почему бы не перенять положительный опыт..?
RadioBOSS создается с другой концепцией, нередео противоположной тому, что принято в большинстве других программ для автоматизации радио. В некоторых других программах добавление трека это целая операция, заполнение каких-то "карточек треков", "импорт трека в базу", а нередко даже сама установка программы - целая эпопея с настройками баз данных, паролей, связка модулей и черт знает что. Поэтому перед тем, как что-то "перенять" нужно очень крепко подумать... То же добавление простейшей локальной базы, кажется, принесло больше проблем, чем решило.
 
Ian сказал(а):
Я впервые встречаю проблемы с работой над файлами FLAC именно в программе RadioBoss.
Больше нигде таких проблем нет.
Кстати работа с пользовательскими тегами -- ту даже.
В RadioBOSS нет проблем с тегами и FLAC. Тут дело в другом: в FLAC нельзя писать тег APEv2. А именно в этом теге хранится доп. информация (независимо от формата файла). Можно было сделать и по другому, записывая доп. поля в тег Vorbis Comment, но технически это сложнее (ввиду внутренней архитектуры) и поэтому были выбраны потоки.

Ian сказал(а):
Кстати работа с пользовательскими тегами -- ту даже.
А что не так с пользовательскими тегами?

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

Вот это
Ian сказал(а):
Хоть бы предупредили, что "Ребята, в новой версии, при конвертации ... будет стёрта доп.информация с разметками, будьте осторожны!"
неправильно. Ничего не удаляется, даже при конвертации. Единственное, может удалиться при неправильной конвертации - когда выбрано не то направление.
 
Ian сказал(а):
не засорять общение вашими совершенно не относящимся к теме работы БД пустыми рассуждениями и домыслами?
А вот вы и объясните каков практический смысл, для чего вообще в тэгах какие-то метки и пр." рюшечки"? Разве без этого нельзя обойтись другими методами? А то тут скоро с десяток страниц нафлудим и к консенсусу не придем.
Мне это напоминает рассуждения на тему "сколько пикселей в фотографии, может ещё один пиксель добавим"?  ;)
Ian сказал(а):
(кроме самого умного Новосёла, с радиостанции "Толстушка", разумеется)
Хорошо смеётся тот, кто смеётся последним.  ;D
Сравним ваш и мой эфир и я на 100500% уверен, что сторонний радиослушатель не найдет даже 3 отличий. Когда коту делать нечего...
 
Новосел, а где можно услышать в сети вашу станцию, очень интересно? Предвидя ответ-нигде, готов предоставить Вам БЕСПЛАТНО ресурсы своего icecast сервера в любом качестве битрейта.
 
an-kov сказал(а):
Новосел, а где можно услышать в сети вашу станцию, очень интересно? Предвидя ответ-нигде, готов предоставить Вам БЕСПЛАТНО ресурсы своего icecast сервера в любом качестве битрейта.
Он играется судя по всему с Шоуткастом у себя на ПК )))
 
Novossyol сказал(а):
А вот вы и объясните каков практический смысл, для чего вообще в тэгах какие-то метки и пр." рюшечки"?
Метки используются для войсдропов, нарезок, для установки начала-конца трека (например, отрезать очень длинную инструментальную часть), для задания индивидуальных параметров микса и множество других параметров. Также, там сохраняется количество запусков трека и дата-время последнего запуска.
 
djsoft сказал(а):
Если расширять базу данных, добавив сетевой вариант, и также добавить возможность из программы переименование файлов с обновлением нового пути в базе - такой вариант, наверное, будет более приемлемым.
- " Если", то - да! :) Я ж с этого, собственно, и начал свою точку зрения выказывать...
Но если нет, то создание дополнительных мета-файлов - было бы отличным решением.

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

gJ6fod1-RNe01DS2IQRjIw.png


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

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


 
scorp сказал(а):
Он играется судя по всему с Шоуткастом у себя на ПК )))
Всё свое ношу с собой. Канала в 100 мбит хватит на всех и ещё останется.)))
Вещание нерегулярное. Технические работы и отладка оборудования.
Сейчас вот думаю сайт переносить на свой домашний комп, так как не имеет экономического и практического смысла его держать на хостинге.
djsoft сказал(а):
Метки используются для войсдропов, нарезок
А что разве стандартного кроссфейда не хватает для большинства случаев?
djsoft сказал(а):
(например, отрезать очень длинную инструментальную часть)
Я это делаю сразу в редакторе при подготовке трека в музбазу. Нормализую трек, отрезаю тишину в начале и конце трека и сохраняю в mp3 320/44100.
djsoft сказал(а):
для задания индивидуальных параметров микса и множество других параметров.
В каком % случаев это очень необходимо и просто незаменимо?
djsoft сказал(а):
Также, там сохраняется количество запусков трека и дата-время последнего запуска.
Это мы знаем, для того пока и оставляем тэг в треке, ни для чего более.
 
Novossyol сказал(а):
Я это делаю сразу в редакторе при подготовке трека в музбазу. Нормализую трек, отрезаю тишину в начале и конце трека и сохраняю в mp3 320/44100.
А мы не занимаемся такой ерундой и не пересжимаем треки лишний раз, просто расставили метки и все. Красота и трек не тронут. А Вы себе играйтесь дальше. )))
 
Novossyol сказал(а):
Я это делаю сразу в редакторе при подготовке трека в музбазу. Нормализую трек, отрезаю тишину в начале и конце трека и сохраняю в mp3 320/44100.

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

Извиняюсь за дачу ложных показаний  :)
Направление конвертации выбирал правильное, после конвертации, так же показывало (28 files processed), так как 28 файлов и конвертировал.
Пробовал и обратную конвертацию из SQLite в APEv2, и так же ничего не происходило, то есть при просмотре файла тегов APEv2 через Mp3tag и в файле ничего не менялось, то есть данные оставались старыми.
Попробовал сегодня, все метки начали сохраняться, мистика.
Еще раз извиняюсь.
 
scorp сказал(а):
А мы не занимаемся такой ерундой и не пересжимаем треки лишний раз, просто расставили метки и все. Красота и трек не тронут. А Вы себе играйтесь дальше. )))
Однако как вы проводите нормализацию уровня, если трек тихий? Я же все треки в редакторе нормализую под 0 дБ, но "без зашкала".
Да ради бога, я тоже не пересжимаю, просто разворачиваю его в редакторе из mp3 в РСМ, а потом сохраняю с бОльшим битрейтом. Качество не страдает, так как контейнер 320 кбит с бОльшей пропускной способностью, чем первоисточник либо равный ему и не спорить. Сверялся с оригиналом никаких изменений по звуку - ничто, ничего и никуда не теряется, во всяком случае в диапазоне 30-15000 гц, что было то и осталось! А вы верьте мифам "аудиофилов" и играйтесь себе дальше с базой и тэгами. )))
avg сказал(а):
То есть, даже если трек до этого был, допустим 128/44100, Вы его потом сохраняете в 320/44100 ?
Да, а что здесь удивительного? Я для себя всё привожу к одному вещательному стандарту - не люблю разношёрстность.
Но треки в 128 кбит я стараюсь не брать в работу вообще, только ввиду крайней необходимости, когда трек ну уж "очень эксклюзивный" и его не найти в 320 кбит.
 
Novossyol сказал(а):
Однако как вы проводите нормализацию уровня, если трек тихий? Я же все треки в редакторе нормализую под 0 дБ, но "без зашкала".
Это похвально, что Вы перед добавлением трека в базу, проводите нормализацию, но извольте, что за аудио процессор используете, AGC и клипер с этим справиться на ура, все будет звучать на одном уровне.

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

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

Вложения

  • spektr.jpg
    spektr.jpg
    186,8 КБ · Просмотры: 446
avg сказал(а):
но извольте, что за аудио процессор используете, AGC и клипер с этим справиться на ура, все будет звучать на одном уровне.
Не будет. Не вытягивает Стереотул. У вас может и вытягивает.
avg сказал(а):
А вот размер файла увеличился с 3.73 MB в 9.32 MB
При нынешних объёмах HDD проблема неактуальна. Я с 2010 года даже 1 ТБ HDD не менял на больший. )))
 
avg сказал(а):
Однако как вы проводите нормализацию уровня, если трек тихий? Я же все треки в редакторе нормализую под 0 дБ, но "без зашкала".
Это похвально, что Вы перед добавлением трека в базу, проводите нормализацию, но извольте, что за аудио процессор используете, AGC и клипер с этим справиться на ура, все будет звучать на одном уровне.
Вот-вот, я к примеру включил AutpAmp в РБ + поставил Stereo Tools и вообще бомба, плюс там и спектр немного можно скорректировать если урезан... на слуха становиться заметно приятнее.. и не надо заниматься ерундой типа нормализаций и прочего... все на лету..
 
Назад
Верх