Cómo funciona ManiaGAI

DanceGAI es el equipo detrás de ManiaGAI, un generador de beatmaps de osu! mania con IA. DanceGAI está construyendo infraestructura de IA que convierte la música en experiencias jugables, y ManiaGAI es su primer producto: subes una canción y genera un mapset de osu! mania completo y jugable —timing, notas y una serie de dificultades— empaquetado como un .osz estándar. La canción puede ser un archivo de audio subido o la canción de un beatmapset de osu! que enlaces; en ambos casos solo se usa el audio, nunca los mapas existentes. La versión 2 del sistema está en funcionamiento en este sitio. osu! mania es el primer formato de salida: el sistema está pensado para los juegos de ritmo de scroll vertical (VSRG) en general.

Esta página explica cómo funciona y por qué está diseñado así. Somos abiertos sobre la arquitectura y las decisiones de ingeniería; no publicamos los detalles que alguien necesitaría para reconstruirlo. Cuando una cifra todavía no es pública, la página lo dice en lugar de adivinar.

Resumen técnico

Un beatmap no es una transcripción

La forma obvia de plantear la generación automática de beatmaps es “entra audio, red neuronal, salen notas”. En la práctica, ese planteamiento produce mapas que técnicamente siguen la música y son desagradables de jugar. Un buen mapa de osu! mania se parece más a un arreglo que a una transcripción: un mapper decide qué sonidos merecen notas, qué densidad debe sentirse en una sección, dónde poner un jack o una nota larga, cómo fluyen los patrones entre las manos y cómo cambia todo eso entre una dificultad Easy y una Expert.

Por eso ManiaGAI trata la generación de beatmaps como una secuencia de problemas distintos: entender la música, planificar la jugabilidad, colocar las notas y comprobar el resultado:

1. Música
2. Comprensión
3. Planificación
4. Generación
5. Refinamiento
6. Beatmap

1. Comprensión musical

Todo lo que viene después depende de una imagen precisa de la canción. La primera etapa convierte el audio en bruto en dos cosas: una cuadrícula de timing y una representación musical de alta resolución de cada momento de la canción.

Timing. Las activaciones de pulsos y de inicios de compás provienen de Beat This, un modelo de beat tracking de código abierto. Convertir esas activaciones en una cuadrícula de timing de osu! —BPM y offset, incluidas las canciones cuyo tempo cambia— es nuestro propio método de ajuste de cuadrícula, y produce la misma familia de cuadrículas con la que se entrenaron los modelos de generación. El timing es lo primero que notan los jugadores: un mapa desfasado unos pocos milisegundos del pulso es injugable por buenos que sean sus patrones, así que se trata como un problema de primer orden, no como un paso de preprocesamiento.

Características musicales. El audio se codifica con MERT-v1-95M, un modelo autosupervisado de representación musical, y se alinea con la cuadrícula de timing, de modo que los modelos ven la música pulso a pulso: ataques, textura, intensidad y cómo cambian a lo largo de la canción. Los tramos silenciosos se detectan por separado, para que nunca se coloquen notas sobre ellos.

2. Planificación del beatmap

La decisión de diseño central de ManiaGAI es separar lo que debe ocurrir de cómo se colocan las notas.

Un modelo de planificación dedicado lee la representación musical y decide la estructura de jugabilidad de toda la canción antes de que exista ninguna nota: qué densidad debe tener cada sección, qué tipos de patrones van en cada sitio, cómo debe subir y bajar la dificultad y cómo encaja todo eso con la dificultad y el estilo solicitados. Su salida es un plan que describe el mapa sección por sección —dificultad local y la mezcla de notas largas, jacks y otros tipos de patrones—, no notas.

El planificador es un modelo de difusión gaussiana (unos 6M parámetros). Genera conjuntamente el plan de todas las secciones de la canción, condicionado por la música, el número de teclas y la dificultad y el estilo objetivo. La difusión encaja bien con esta tarea: un plan es una descripción suave y continua de una canción, y generarlo como un todo permite al planificador equilibrar toda la canción a la vez.

Planificar a este nivel le da al sistema algo de lo que carece un modelo nota a nota: una visión de toda la canción. Se puede planificar que un estribillo golpee más fuerte que la estrofa anterior; se puede planificar que un breakdown respire.

3. Generación de notas

Un segundo modelo convierte el plan en la colocación real de las notas: qué columnas, qué notas son toques y cuáles son notas largas, cómo se conectan los patrones. La planificación determina la estructura; la generación de notas convierte esa estructura en notas jugables que siguen tanto el plan como el audio.

El modelo de notas es un transformer no autorregresivo de tipo MaskGIT (unos 51M parámetros). Los mapas se representan como tokens de patrones discretos y, en lugar de escribirlos uno a uno de principio a fin, el modelo rellena el mapa entero y luego lo refina en varias pasadas: fija las notas de las que está seguro y revisa el resto. Cada pasada ve el contexto a ambos lados de cada sección, que es lo que mantiene los patrones coherentes a lo largo de una canción. Cómo se programan esas pasadas a lo largo de una canción es nuestro propio método de refinamiento.

Por qué ManiaGAI usa un Planner + Noter (en inglés) →

4. Generación controlable

ManiaGAI no es un sistema de “generar y cruzar los dedos”. La misma canción se puede generar con controles explícitos, y los controles forman parte de lo que los modelos aprendieron a seguir:

• Número de teclas: de 4K a 9K.
• Dificultad: cualquier selección de dificultades en estrellas de ★1 a ★10. Una canción produce un mapset completo, de Easy a Expert, en una sola ejecución.
• Estilo: características de jugabilidad como la proporción de notas largas y cuántos patrones de jack, LN inverso, LN cortas y delay contiene un mapa, cada una ajustable en el generador.
• Densidad: se deriva de la dificultad objetivo y del plan, no de una regla fija.

Todas las dificultades se generan a partir de la misma comprensión de la canción, así que un mapset se lee como una sola familia de mapas y no como mapas sin relación entre sí. A continuación, trabajamos hacia representaciones de estilo aprendidas: describir un estilo de mapping con ejemplos en lugar de con un puñado de controles deslizantes.

5. Validación y control de calidad

Antes de que un mapa te llegue, el sistema lo comprueba:

• Timing: los puntos de timing escritos se comprueban con la cuadrícula detectada.
• Notas no válidas e injugables: se resuelven las notas superpuestas, las notas largas rotas y las colocaciones que el juego no puede representar, y nunca se colocan notas sobre audio claramente silencioso.
• Dificultad medida: la dificultad en estrellas de cada mapa se mide con el mismo algoritmo que usa osu!, y la dificultad recibe su nombre según el valor medido, no el solicitado.
• Coherencia en todo el mapset: un mapa que sale más fácil que el que debería ir por debajo de él, o casi idéntico en dificultad a uno vecino, se descarta en lugar de entregarse. En el generador ves qué estrellas se descartaron y por qué.
• Validez de la salida: el resultado se empaqueta como un .osz estándar con audio, fondo y hitsounds que se importa directamente en osu!.

En cifras

Canciones en el conjunto de entrenamiento

86,255

Mapas de entrenamiento

150,622

Mappers

~14,500

Audio único

4,227 h

Características de entrenamiento en disco

~0.7 TB

Cómputo de entrenamiento (registrado, linaje de producción)

~580 horas de GPU

Ejecución final del modelo de notas

~4 días

Parámetros del modelo

~57M (51M notas + 6M planificador)

Generación de un mapset completo

~20 s

Modos de teclas

4K–9K

Rango de dificultad

★1–★10

Dificultades por ejecución

hasta 10 (menos en canciones largas)

Datos de entrenamiento

Los modelos de producción aprenden de 150,622 mapas de osu! mania hechos por humanos de 86,255 canciones —4,227 horas de audio único— creados por unos 14,500 mappers. La mayor parte del trabajo en un sistema así no es el modelo; son los datos: decidir qué cuenta como un mapa del que vale la pena aprender, asegurarse de que el timing de cada ejemplo de entrenamiento sea correcto y representar los mapas de una forma que capture lo que los hace jugables.

Explora el dataset de entrenamiento (en inglés) →

Evaluación: precisión del timing

Comparamos nuestro timing con el timing humano en todos los mapsets ranked de osu! mania con un único tempo constante que pudimos evaluar —2,501 canciones—, junto con el modo de timing del proyecto de código abierto Mapperatorinator y ManiaGAI v1, nuestro detector anterior. Una canción cuenta como correcta cuando el BPM coincide con el del mapper (admitiendo mitad/doble de tempo) y la fase del pulso está dentro de la tolerancia indicada.

Solo canciones ranked de tempo constante; “una línea de timing” = la canción se sincronizó con una sola línea, como hizo el mapper (una línea extra en una canción de tempo constante es un cambio de tempo falso). Medido con una configuración cercana, pero no idéntica, a la que está en producción.

Lee el benchmark de timing completo (en inglés) →

Entrenamiento

El planificador y el modelo de notas se entrenan por separado, cada uno sobre la representación con la que trabaja: el planificador como un modelo de difusión gaussiana sobre una descripción gaussianizada de la jugabilidad de cada sección; el modelo de notas, mediante predicción de tokens enmascarados sobre tokens de patrones. Las muestras de entrenamiento se equilibran entre números de teclas y niveles de dificultad para que los mapas de 8K y ★10 no queden ahogados por los de 4K y ★4, y el modelo de notas se entrena con precisión mixta.

Cada cambio se juzga por los propios mapas generados —precisión del timing, dificultad medida frente al objetivo, jugabilidad—, no solo por la pérdida de entrenamiento.

Inferencia y rendimiento

Un sistema de IA útil no depende solo de la calidad del modelo; también tiene que ser lo bastante rápido para usarlo. Una solicitud a ManiaGAI se ejecuta así:

1. En tu navegador: la canción se decodifica, se normaliza su volumen y se vuelve a codificar en cuanto eliges el archivo, mientras todavía estás eligiendo los ajustes, así que la GPU nunca espera al procesamiento del audio.
2. Comprensión musical en la GPU: Beat This y MERT, con el ajuste de cuadrícula ejecutándose en la CPU en paralelo con MERT.
3. Planificación y generación de notas para todas las dificultades solicitadas en una sola pasada por lotes.
4. Validación: medición de la dificultad en estrellas, comprobaciones de coherencia.
5. Empaquetado del .osz y, después, la descarga.

Los workers de GPU arrancan desde un snapshot precargado, así que incluso un worker en frío está listo en segundos en lugar de pasar ese tiempo cargando modelos. Un mapset completo tarda unos 20 segundos de cómputo de GPU para una canción típica, sin contar la subida, la cola ni la descarga; una canción medida de 2:50 con cinco dificultades tardó 12.7 segundos en una NVIDIA T4: timing y características musicales 3.8 s (en paralelo), planificación 1.0 s, generación de notas para las cinco dificultades 6.1 s.

Cómo hicimos rápida la generación (en inglés) →

Lo que no publicamos

Publicamos los principios de la arquitectura, las decisiones de ingeniería que hay detrás y lo que el sistema hace y no hace, incluidos los modelos abiertos sobre los que construimos (Beat This, MERT) y las familias a las que pertenecen nuestros propios modelos (difusión gaussiana, MaskGIT). No publicamos los métodos que desarrollamos nosotros ni los detalles que permitirían a alguien reproducir el sistema: cómo se ajusta la cuadrícula de timing y se fusionan sus segmentos de tempo, cómo se programan las pasadas de refinamiento del modelo de notas a lo largo de una canción, cómo se condicionan los modelos, las arquitecturas exactas, las funciones de pérdida y los hiperparámetros, y cómo se obtienen, filtran y construyen los datos de entrenamiento. Esa es la línea entre ser transparentes sobre lo que construimos y entregar la receta. Cuando afirmemos algo sobre la calidad, pretendemos respaldarlo con benchmarks publicados, no con adjetivos.

Lo que viene

Más allá de osu! mania. ManiaGAI está diseñado en torno a una representación de la jugabilidad que no es específica de osu! mania: notas y notas largas en columnas, colocadas sobre una cuadrícula de timing y condicionadas por una dificultad objetivo. osu! mania es el primer formato de salida, no el límite del sistema.

• #osumania
• #osu
• #VSRG
• #RhythmGames
• #AIBeatmapGenerator
• #BeatmapGeneration
• #RhythmGameAI
• #AIMusicToGame
• #MaskGIT
• #DiffusionModels
• #MERT
• #BeatThis
• #ManiaGAI
• #DanceGAI