abxtestcom
20.07.2024 #Dev

ABXtest — разработка

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

Хочу поделиться с вами своим домашним проектом, который я разработал с новой нейронкой v0.dev. Это веб-приложение для тестирования качества аудио, и я горжусь, что мои руки дошли наконец до него. Домен я купил в далёком 2014 и он всё ждал момента. Vercel могли бы пораньше сделать свою нейронку.

Идея и Цель

Идея проекта возникла из моего личного интереса к качеству аудио и стремления понять, насколько различимы различные уровни битрейта для обычного пользователя. Цель проекта — создать интуитивно понятный инструмент, который позволяет пользователям тестировать свои способности различать качество аудио. В целом, проект отвечает на вопрос: насколько качественна эта акустика для меня? Ведь какой смысл в твоих Yamaha YH-5000SE за 500 тысяч рублей, если ты не слышишь разницу между MP3 с битрейтом 96 кбит/с и Lossless? Этот тест отвечает на этот вопрос очень основательно. Подробнее об этом методе можно почитать в Википедии.

Сравнивать будем самые популярные форматы на стриминговых сервисах:

  • 96 кбит/с – Используется в интернет-радио и подкастах.
  • 128 кбит/с – Качество бесплатных версий стриминговых сервисов (TIDAL Free, Deezer Free, Spotify Free).
  • 192 кбит/с – Приемлемое качество для Spotify, Apple Music и других.
  • 256 кбит/с – Высокое качество в премиум-подписках (YouTube Music Premium, SoundCloud Go+).
  • 320 кбит/с – Наивысшее качество MP3 (SoundCloud HQ, Spotify Premium).
  • Lossless – Формат без потерь для аудиофилов (Deezer HiFi, Amazon Music Unlimited).

Техническая Реализация

В первой итерации необходимо собрать MVP. Для того, чтоб собрать обратную связь с пользователей и понять, куда двигаться дальше.

Построим логику, как это всё должно работать

graph TD
  A[Начало теста] --> B[Загрузка теста: mp3_96, flac и Неизвестный вариант X]
  B --> C[Воспроизведение аудиофайлов]
  C --> D1{Выбор пользователя}
  
  D1 --> |"Это A"| E[Проверка выбора]
  D1 --> |"Это B"| E[Проверка выбора]
  D1 --> |"Я не знаю"| N[Пропускаем трек]

  E --> F{Угадал два раза подряд?}
  F --> |"Да"| G[Увеличиваем качество mp3 до 128]
  F --> |"Нет"| H{Не угадал два раза подряд?}
  
  G --> I{Увеличиваем качество?}
  I --> |"Да"| J[Увеличиваем качество mp3 до 256]
  I --> |"Нет"| K[Завершение теста]

  J --> L{Увеличиваем качество?}
  L --> |"Да"| M[Увеличиваем качество mp3 до 320]
  L --> |"Нет"| K[Завершение теста]

  M --> N1{Угадал на 320?}
  N1 --> |"Да"| O[Выводим, что слышит разницу между 320 и flac]
  N1 --> |"Нет"| P[Завершение теста на качестве, на котором не угадал]

  H --> |"Да"| K[Завершение теста]
  H --> |"Нет"| N[Пропускаем трек]

  N --> C[Воспроизведение аудиофайлов]

Посмотреть схему

Особенности приложения

Интерактивный интерфейс: Не должно быть задержек в проигрывателе, поэтому все треки необходимо загружать заранее в момент смены теста. При загрузке треков, пользователь должен видеть прогресс.

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

Отображение прогресса теста: Количество карточек будет разное, в зависимости от того, как далеко дойдет пользователь, но он должен понимать сколько ему ещё осталось.

Поддержка многоязычности: Поскольку домен находится в зоне .COM, поддержка нескольких языков сделает его доступным для более широкой аудитории.

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

FAQ нужен из коробки, чтоб убрать большую часть вопросов.

Как это устроенно

Мы делаем MVP, поэтому должно быть дёшево и быстро.

  1. Фронтенд:
    • Отправляет HTTP-запросы на бэкенд только на загрузку списка треков и получение самих треков.
    • Получает и обрабатывает JSONAPI-ответы.
    • Управляет UI через JavaScript/jQuery.
    • Главный файл фронта – тут вся логика, постарался прокомментировать каждый чих.
  2. Бэкенд:
    • Обрабатывает запросы через API (Slim Framework).
    • Возвращает данные в формате JSON.
    • Управляет логикой доступа к данным через NGINX.
    • В беке даже смотреть особо нечего.
  3. Взаимодействие:
    • Фронтенд -> Бэкенд: запрос треков.
    • Бэкенд -> Фронтенд: ответ с данными.
    • Фронтенд обновляет UI на основе полученных данных.