Войти
ПрограммированиеФорумЗвук

Разработка архитектуры системы хранения текстовых меток для звуковых файлов.

#0
17:01, 2 окт. 2013

Вот на этом интерфейсе: http://audigger.sourceforge.net/ru/ можно увидеть пару текстовых дорожек вдоль звуковой дорожки, показанной в виде сонограммы, звук можно показывать и в виде волны ( http://a.fsdn.com/con/app/proj/audigger/screenshots/2013-07-05---… -34-45.85.jpg ) — не важно, на сонограмме больше визуальной информации о звуке.

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

База треков — это хранилище множества треков разных типов вместе со связями между ними. Физически это может быть папка с файлом index, база в СУБД, база в сетевом облаке (доступная через определённое API) и т.п. Главная функция базы — поиск треков по связям с другими треками.

Например: когда я открываю файл /home/myname/audio/123.wav в своём редакторе и создаю там же текстовую дорожку для него, то текствая дорожка сохраняется в базе и получает связь со значением хеш-функции от данных файла 123.wav. Если я открываю 123.wav на следующий день, даже перемещённый/переименованный, то программа просит у базы все треки, ассоциированные с hash этого файла и пользователь видит свои текстовые треки.

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

То есть, для работы с программой, пользователь создаёт и управляет неким множеством баз.

Плюсы:

  • не мусорим в каталогах пользователя, где он до нашего появления хранил звуковые файлы.
  • не зависим от имён и местоположения файлов, а только от содержимого
  • удобно организовывать текстовые дорожки по базам — «лекции физика», «база шумов» и др. Для одного аудио-файла можно открыть несколько текстовых дорожек из разных баз.
  • если базу расшарить, то несколько людей смогут ей пользоваться, например коллективно аннотируя большой объём звуковых данных.

  • Минусы:
    Зависимость от сожержимого: отредактировал wav-файл — хеш поменялся, текстовые дорожки отвалились. Но текстовых дорожек для аудио-файла обычно немного, передобавить вручную не проблема. Но обычно аннотируют "константные" файлы, которые не нужно редактировать. Обычно, текстовые метки присваивают неким неизменяемым звуковым трекам, выделяя в них что-то интересное для организации этих фрагментов. Конечно ты мог редактировать в нашей программе и тогда дорожки бы пофиксились автоматически, но свободу выбора редактора никто не отменял.


    #1
    21:17, 3 окт. 2013

    бери SQLite и вперед, хватит и одной базы

    #2
    0:15, 4 окт. 2013

    Pushkoff
    Это вы про реализацию одного из частных случаев.

    ПрограммированиеФорумЗвук

    Тема в архиве.