Просмотр полной версии : Проект усовершенствования ИС записей МДС
:arrowl: (http://www.mdteam.ru/forum/viewtopic.php?t=983&start=14) Надо бы некое ТЗ наваять, глядишь появится время и родится прога или найдется.Для этого неплохо было б знать примерные возможности.. ибо своё виденье программы максимум я излагал в письме, а для реалистичной программы нужно знать, какие средства есть в активе. На мой взгляд, система должна обладать примерно такими возможностями и особенностями (в порядке от основных к опционным).
0. Способность, имея доступ к mp3-файлу с записью, сопоставлять ему набор числовых параметров (для краткости - хеш), одинаковый для файлов, содержащих один и тот же аудиопоток (т.е. дающих при декодировании идентичные wav-файлы), и различный для файлов с разным аудиопотоком. /* На мой взгляд, это главное, что нужно сделать обязательно, т.к. это даёт возможность отобразить множество громоздких аудиофайлов в набор уникальных компактных хешей, которые удобно хранить и пересылать по сети. Можно также думать о способе распознавания частично повреждённых копий одной записи или даже схожих записей в разном битрейте.. но это всё уже "совсем другая история". */ Эту возможность хорошо бы иметь в виде отдельного маленького исполняемого модуля с интерфейсом командной строки для использования в различных частях системы (например в клиенсткой части и в серверной).
1. Иметь централизованную базу данных хешей, сопоставляющую всевозможные доступные хеши различных вариантов записей идентификаторам соответствующей записи из каталога. Желательна возможность экспорта текущей версии БД (в каком-либо текстовом виде или XML..) для автономного использования в клиенте.
2. Клиентский исполняемый модуль (бинарник в идеале), способный по набору mp3-файлов и локльной версии БД хешей и записей осуществить распознавание известных ему записей с возможным переименованием файлов и/или записью информации в ID3-теги.
3. Возможность загрузки с сервера на клиент апдейтов базы данных и отправки с клиента на сервер информации о ранее неизвестных записях (все атрибуты файла, включая имя, размер, дату, параметры кодирования и прочее плюс, возможно, пользовательский комментарий).
Вот, собственно, и всё.. по-моему, ничего особо сложного или трудоёмкого..
0 - подсчёт хешей файлов;
1 - БД, сопоставляющая хеши записям;
2 - клиент, обрабатывающий пользовательские файлы;
3 - средство обмена и синхронизации клиент-сервер.
0 - подсчёт хешей файлов;
1 - БД, сопоставляющая хеши записям;
2 - клиент, обрабатывающий пользовательские файлы;
3 - средство обмена и синхронизации клиент-сервер.
Небольшая корректировка. IMHO
Пункт 3 можно всецело отдать любому менеджеру закачек, благо таковых завались и еще останется. Писать свой велосипед не разумно, да и не будет столько времени чтобы этот велосипед сравнился хотя бы с ReGet или FlashGet
"клиент, обрабатывающий пользовательские файлы" пусть просто все будет сравнивать и если нужно качать то запускать качалку из установленных у пользователя.
Так же небольшое обьявление, люди знающие C++ (Visual Studio) или Delphi и желающие написать пользовательский клиент присоединяйтесь!
Серверная часть моя. Но вот для клиентской нужен человек.
Так что кто может, умеет и готов взяться говорите!
bosom, ты меня немножко не так понял насчёт скачивания: в том, что я предлагаю, никакого скачивания mp3-файлов не подразумевается (на крайняк просто сформировать текстовый файл со ссылками, но это всё пока "out of scope"); я говорю только о скачивании апдейтов базы данных, экспортированной в подходящий для обмена формат; под базой данных имеется в виду тоже вполне конкретная вещь: привязка хешей к произведениям (точней прочтениям) с минимально необходимой инфой: название произведения, автор, дата эфира. В принципе, если почему-либо не хочется связываться со скачиванием вообще - можно просто проверять наличие апдейта и просить пользователя скачать этот файлик и кинуть в папку программы.. но это всё мелочи.
P.S.: Клиентскую часть можно сделать пока вообще без графического интерфейса, в стиле UNIX'а, интерфейс можно дописать когда-нибудь потом.. В принципе я могу попробовать накатать что-нибудь на PHP.. вот только не знаю, как у него с компилируемостью, надо будет узнать.. Вообще-то, вроде, есть коммерческий компилятор PHP..
Сейчас ещё пара моментов в голову пришла.
Во-первых, было бы очень неплохо сделать хеширование независимым от выставленного в файле ReplayGain (или как там это правильно зовётся.. короче те показатели уровня громкости, которые прописываются без перекодирования программами типа mp3gain). Потому как некоторые файлы очень хочется отнормализовать, чтобы не было перепадов уровня громкости.. хотелось бы, чтобы это был "разрешённый приём".
Во-вторых, надо сразу предусмотреть такую связь в БД, чтобы поддерживалась нарезка одного произведения на произвольное число частей и наоборот: склеивание разных произведений одного эфира или разных эфиров, содержащих одно произведение. Тут вопрос не в том, как лучше хранить записи, а в том, что они де факто уже хранятся в множестве различных вариантов. Я не имею в виду, чтобы программа сама как-то понимала, что такой-то файл является объединением таких-то других файлов.. просто заложить в структуру БД достаточно гибкую систему привязки.
Сейчас ещё пара моментов в голову пришла.
Во-первых, было бы очень неплохо сделать хеширование независимым от выставленного в файле ReplayGain (или как там это правильно зовётся.. короче те показатели уровня громкости, которые прописываются без перекодирования программами типа mp3gain). Потому как некоторые файлы очень хочется отнормализовать, чтобы не было перепадов уровня громкости.. хотелось бы, чтобы это был "разрешённый приём".
Во-вторых, надо сразу предусмотреть такую связь в БД, чтобы поддерживалась нарезка одного произведения на произвольное число частей и наоборот: склеивание разных произведений одного эфира или разных эфиров, содержащих одно произведение. Тут вопрос не в том, как лучше хранить записи, а в том, что они де факто уже хранятся в множестве различных вариантов. Я не имею в виду, чтобы программа сама как-то понимала, что такой-то файл является объединением таких-то других файлов.. просто заложить в структуру БД достаточно гибкую систему привязки.
1. Громкость прописывается в файле, соответственно файл уже меняется и меняется его контрольная сумма. Тут думаю ничего не получится. Если файл изменени то все, у него другая контрольная сумма. А вот на счет подсчета контрольной суммы без учета тегов IDv2, IDv3 это решаемо, так как где находятся теги известно и соответственно известно что надо не считать а пропускать.
2. Каталог сделан так, что к записи рассказа можно прикрепить сколько угодно файлов размещенных на каких угодно серверах. Это и есть то что ты вторым предложил? Если на сервере эти кусочки будут доступны для хэширования то контрольные суммы тоже будут доступны.
P.S. Сейчас с форумом закончим основные настройки и следующий этап расширение возможностей БД и каталога.
извиняюсь что врываюсь в эту тему, но я посчитал её более подходящей.
я тут задался целью создать некую навигационную базу для всех рассказов. особо мозги не стал конопатить и создал её просто в экселе.
а теперь главная трудность (ну вообще не трудность так мелочь)
почему когда я копирую список авторов и рассказов и вставляю их куда либо, всегда перед названиями обноруживаются два пробела? может обьяснить с чем это связано? и вообще это для вас важно или просто это некий не досмотр.
вставляю их куда либо, всегда перед названиями обноруживаются два пробела? может обьяснить с чем это связано? и вообще это для вас важно или просто это некий не досмотр.
А если ты в Excel-е нажимаешь F2, входишь в режим редактирования ячейки, перед названиями есть два пробела? Если нет, то тогда всё просто, это особенность копирования данных из Excel. Копируй через F2, выделить и скопировать.
кстати ребят а чего за хрень такая! в сообщениях заглавные буквы автоматом превращяються в обычные маленькие? по крайней мере в новой теме у меня так в двух постах было. а счас посморим.
ну вот я же говорил...
может это что то с моим компом, брузёром?
кстати ребят а чего за хрень такая! в сообщениях заглавные буквы автоматом превращяються в обычные маленькие? по крайней мере в новой теме у меня так в двух постах было. а счас посморим.
ну вот я же говорил...
может это что то с моим компом, брузёром?
функция форума "антикрик".
а это чё такое? как то не привычно общаться без заглавных буковок. ну лана вобщем думаю мера не с неба свалилась, видимо вынужденная.
Powered by vBulletin® Version 4.2.0 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot