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

[Ian]

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

 

[scorp]

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

Он все никак не вкурит этого! )))

если опция с базой будет востребована, будет еще одна опция для использования уже сетевой базы (MySQL или подобной)

Все востребовано что есть, ничего убирать не надо, а кроме сетевой версии хотелось бы видеть SQLite для полноценной работы со всей базой и т.д. (дополнительно к MySql, на выбор).
Хватило бы и АПИ, но он такой лысый и не гибкий, а с базы все просто достать, отфильтровать, отсортировать, поиски, и пр.

Надо бы окошко по ALT+4 сделать пошире и/или поле в нем сделать многострочным.. (и там кстати нету перевода, так для полноты его)
А еще сделать возможность редактирования имени прямо в окне TrackTools сверху там где указан путь к файлу. И я до сих пор не понял что мешает РБ сразу обновить в базе путь к файлу после переименования (если оно делается через РБ). С плейлистами понятно, там РБ ходить менять не будет, но там где он имеет контакт (база, задания и пр) может менять на ходу. И никакие утилиты тут не нужны вообще! То, что РБ может отследить на лету он может и поменять там, где это видит. Вот и все... А остальное ручками. Но то что можно сделать можно сделать!

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

Та в базе поменять путь после переименования это вообще пустяк, один запрос и 1 сек. Есть старый путь, есть новый и элементарный запрос update и все. Проблем вообще ноль с этим.

 

[Ian]

Ещё вопрос.
Я успел конвертировать теги APEv2 в SQLite в версии RadioBoss 5.6.0.7
Однако решил, что старая версия работает с файлами лучше. Вернул старую версию -- 5.5.5.0

И о, как я удивился!
Все файлы, которые я конвертировал... имеют пустые теги (!!!)
Абсолютно все!

Вопрос.
Вот зачем, скажите мне, на милость, удалять из тегов информацию было? Работает программа теперь с БД. Пусть себе работает. Но зачем стирать информацию?!

Вы понимаете, что это многолетний труд, Дмитрий?

 

[Novossyol]

Вы понимаете, что это многолетний труд, Дмитрий?

"Мартышкин труд", слыхали о таком?

Я уже говорил об этом вот здесь:

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

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

 

[scorp]

Ещё вопрос.
Я успел конвертировать теги APEv2 в SQLite в версии RadioBoss 5.6.0.7
Однако решил, что старая версия работает с файлами лучше. Вернул старую версию -- 5.5.5.0

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

С другой стороны как это осталось непроверенным со стороны раазработки - тоже большой вопрос... Или же это какой-то отдельный интересный случай что теги слетели... или это только с ФЛАКами такое...

 

[djsoft]

Можно вернуть принцип хранения метаданных, как это было сделано в той же версии 5.5.5.0 ?
Зачем тут что-то нужно было вообще менять, не понимаю...

Менялось потому, что тег APEv2 не подходит для FLAC файлов - другие плеера такой файл могли не играть или играть некорректно. Поэтому данные перенесены в альтернативный поток. См. мое предыдущее сообщение по поводу WinRar.

Все файлы, которые я конвертировал... имеют пустые теги (!!!)

Похоже, что дело тут в потоках. Новая версия (5.6), если видит FLAC файл, удаляет тег и переносит данные в поток. Старая версия такой файл уже не прочитает.

Надо бы окошко по ALT+4 сделать пошире ...
А еще сделать возможность редактирования имени прямо в окне TrackTools ...
до сих пор не понял что мешает РБ сразу обновить в базе путь к файлу после переименования

Переименование файлов в RadioBOSS это функция десятого порядка. Не думаю, что ей нужно уделять какое-то дополнительное внимание. Смысл окна Alt+4 - редактирование спец. элементов - например, поменять параметры нарезки, трек листа, длительность интернет потока и т.п.

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

Не могут, и ничего тут не слетело. Тем более, что речь тут идет о "доп. информации" (не о стандартных тегах). В случае с FLAC тега как такового нет, и данные хранятся в потоке. Старая версия их "не видит", но на новой - никаких проблем.

 

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

Я успел конвертировать теги APEv2 в SQLite в версии RadioBoss 5.6.0.7
Однако решил, что старая версия работает с файлами лучше. Вернул старую версию -- 5.5.5.0

И о, как я удивился!
Все файлы, которые я конвертировал... имеют пустые теги (!!!)
Абсолютно все!

- Ну Вы не путайте тоже людей! Что Вам мешает снова вернуть информацию из SQLite - в теги треков?

 

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

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

 

[Ian]

С одной стороны где Вы были спрашивается в период тестирования

Всё очень просто.
Сколько там? 3 часа даётся на тест программы?
А то, что проставленные в ней метки не читались боевой версией, на сервере? Я же об этом писал! Много раз повторял Дмитрию, что несовместимость какая-то...

скопировали бы пару треков и проверили все ли будет в порядке

Я так и делал. Писал раз 20 здесь, что обратите внимание -- теги затираются. Меня никто не слушал. Дмитрию я писал, замените вы слово "конвертация". Пугает оно своей необратимостью.
И я был прав.

"Мартышкин труд"

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

 

[Ian]

Менялось потому, что тег APEv2 не подходит для FLAC файлов - другие плеера такой файл могли не играть или играть некорректно. Поэтому данные перенесены в альтернативный поток. См. мое предыдущее сообщение по поводу WinRar.

Я уже связался с Microsoft, с просьбой дать расширенные разъяснения по этому вопросу.
По "Флаку":
Такие проигрыватели, как AIMP, WINAMP, FOOBAR2000, кажется не "слышали" о такой проблеме, Дмитрий.
В особенности Foobar2000. Он может зашить в Vorbis comments почти всё, что вы пожелаете.
Никогда не было таких проблем. В нашем случае есть какие-то проблемы в хранении тегов.
XXI век на дворе. Какие могут быть проблемы?

 

[Ian]

Новая версия (5.6), если видит FLAC файл, удаляет тег и переносит данные в поток. Старая версия такой файл уже не прочитает.

Кто просил вас это делать?

 

[Ian]

Не могут, и ничего тут не слетело. Тем более, что речь тут идет о "доп. информации" (не о стандартных тегах).

А почему в большом количестве файлов я также нашёл пустыми стандартное поле тега [ARTIST] и [YEAR]?

 

[Ian]

В случае с FLAC тега как такового нет, и данные хранятся в потоке. Старая версия их "не видит", но на новой - никаких проблем.

Да, вот только эти данные имеют удивительное свойство стираться,  при копировании файлов с компьютера на компьютер, скажем, по сети, или флешку с FAT32.
Надо же, какой сюрприз!
Кому нужны такие данные, которые будут стираться ОС?
А что с ними будет, при копировании на MacOS?

 

[avg]

К сожалению, с mp3 файлами та же ситуация.
Версии РБ на обоих компьютерах 5.6.0.7
На домашнем компьютере редактируется треки (разметка, теги), в настройках, хранение доп. информации в теге APEv2, далее данные треки синхронизируются со студией, а вот уже на студийном компьютере в РБ делаю конвертацию доп. информации из тега APEv2 в SQLite, далее открываем какой либо из ново добавленных треков в TrackTool и видим что информация: Язык, Пол, метки начала, конца, MIX трека в РБ отсутствуют.

 

[Novossyol]

Не могут, и ничего тут не слетело. Тем более, что речь тут идет о "доп. информации" (не о стандартных тегах). В случае с FLAC тега как такового нет, и данные хранятся в потоке. Старая версия их "не видит", но на новой - никаких проблем.

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

 

[djsoft]

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

Тогда вам нужно будет переименовывать оба файла. Чтобы передать только доп информацию вам нужно будет передавать все эти файлы и раскладывать их в соответствующие папки. Лучше тогда теги использовать.

В особенности Foobar2000. Он может зашить в Vorbis comments почти всё, что вы пожелаете.

Для хранения доп информации используется APEv2, и если его прописать в FLAC, то файл некоторыми программами, и Foobar2k в том числе, считается поврежденным.

А то, что проставленные в ней метки не читались боевой версией, на сервере?

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

А почему в большом количестве файлов я также нашёл пустыми стандартное поле тега [ARTIST] и [YEAR]?

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

 

[djsoft]

Версии РБ на обоих компьютерах 5.6.0.7
На домашнем компьютере редактируется треки (разметка, теги), в настройках, хранение доп. информации в теге APEv2, далее данные треки синхронизируются со студией, а вот уже на студийном компьютере в РБ делаю конвертацию доп. информации из тега APEv2 в SQLite, далее открываем какой либо из ново добавленных треков в TrackTool и видим что информация: Язык, Пол, метки начала, конца, MIX трека в РБ отсутствуют.

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

Нужно уходить от тэгов и проблема станет не актальной.

Так проблемы нет. А вот если программа для радиовещания не читает теги - это дикость.

 

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

Цитата: Максим Осадчий от Июль 15, 2017, 04:00:41 pm
а почему бы не реализовать способ хранения разметки и прочей доп. информации о треке - не в базе, а в дополнительном файле к каждому треку
Тогда вам нужно будет переименовывать оба файла. Чтобы передать только доп информацию вам нужно будет передавать все эти файлы и раскладывать их в соответствующие папки. Лучше тогда теги использовать.

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

 

[scorp]

в дополнительном файле к каждому треку (как это реализовано у некоторых матёрых конкурентов

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

Сколько там? 3 часа даётся на тест программы?

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

 

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

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

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