Hola a todos,
Me gustaria saber donde puedo conseguir las APIs de Aureal (A3D) y de Creative (EAX), he intentado mirar donde descargarlas pero no he podido, con lo cual me queda la duda sobre si son gratuitas o son de pago... alguien me puede ayudar en este sentido?
Gracias
Hola!
La última vez que lo miré eran de pago. Imagino que lo deben seguir siendo... Para que lo necesitabas? ^_^
Sync
Pues hombre, yo... pasaba por aqui y... :sonriendo:
No en serio, pues lo queria para dar soporte en mi motor de desarrollo para las dos APIs, aunque me desilusiona enormemente oir eso, ya que si tenia entendido que A3D era de pago (y tu post me lo confirma), pero lo que no imaginaba era que Creative cobraria por desarrollar para sus tarjetas (Ahhh!!! Ladrones!!! :triste:)
En fin, gracias por avisarme... creo que tendre que volver a plantear lo del sonido, pero es que el hecho de tener que adaptar mis estructuras al formato de Microsoft me revuelve las tripas de una manera... :triste:
Saludos
Pues no se como esta el de Creative, pero vete olvidando de Aureal que dejo el negocio hace ya tiempo.
Un saludo
Ostis, pedrin...
O sea que Aureal quebro y lo mando todo a hacer puñetas? uff... bueno, al menos me quitas un quebradero de cabeza... esperemos que a Creative no le pase lo mismo :sonriendo:
Saludos
Holas, la libreria que utiliza EAX esta en:
http://www.openal.orgestá mantenida por creative y es gratuita.
Para seryu: En qué te basas para decir que está mantenida por Creative?
Para Emotion: Ánimo que el DirectSound, DirectMusic i DirectAudio te cubren todo lo relacionado con EAX y algunas características más avanzadas que soportan las tarjetas de sonido más profesionales.
Un saludo!
Sync :guay:
PD: Creative Y Loki son sponsors de OpenAL... pero es NO quiere decir que mantengan el código de la librería
[ Este Mensaje fue editado por: synchrnzr el 2002-04-23 18:55 ]
Creative y loki son los corren con los gastos para qe esa libreria pueda existir, y sobre todo creative ya qe le interesa qe se use su EAX en los programas.
Si son los qe pagan la manuntencion, no son los qe la mantienen? no digo qe la programen :lengua:
OpenAL es una librería multiplataforma en código abierto que no es propiamente específica de EAX ni de las targetas de Creative.
Es como el OpenGL, que no es específico de las tarjetas de video Sillicon Graphics, por ejemplo.
Sync :guay:
Yo no he dicho que sea especifica de creative, solo dije qe esta mantenida por creative, y eso es cierto.
De todas formas, y por lo que habeis comentado, parece que mi unica alternativa seria para el tema del sonido es DirectSound/Music?
Lo que pasa es que, bueno... he empezado a mirar los ejemplo y las estructuras que vienen sobre DirectX en el apartado musical en el SDK de DirectX8.0a, pero salen siempre los mismos ejemplos y los veo (a mi entender, aunque no tengo experiencia) demasiado simples... no hay por ahi algun sitio web con tutoriales avanzados sobre DirectSound/Music o en el SDK es donde salen los ejemplos mas potentes?
Gracias y un Saludo
Sí los hay aunque no te puedo indicar dónde porque yo me basté con los ejemplos del SDK y ya no he explorado más. Eso que dices tú, que son muy simples: yo creo que esa es la gracia, para aprender van de narices.
De todas formas... qué cosas "superavanzadas" quieres hacer que no estén cubiertas directamente en el SDK? ^_^
Sync :guay:
[ Este Mensaje fue editado por: synchrnzr el 2002-04-25 12:04 ]
Bueno, habia pensado en algo asi como controlar el numero de canales que se ocupan o poder asignarlos. Ya se que puede parecer una estupidez, pero solo es por saber hasta donde puedo llegar con eso, mi idea era hacer un formato propio similar a como trabajan las herramientas tipo Cubase VST y similares, es decir, poder combinar instrumentos MIDI con samples en algun formato y alguna pista en wav, sin contar con la posibilidad (a lo mejor) de poder hacer esa musica espacial o simplemente controlar todos esos aspectos.
Como ya te digo, no tengo mucha experiencia con el sonido y por eso te pregunto :riendo:
Un Saludo
Mmmm, interesante. Hombre, está un poco desfasado eso de utilizar el MIDI. Los motores nuevos (como el mio ^_^) suelen utilizar MP3 para la música de fondo.
Yo me he despegado totalmente del MIDI en los motores porque tiene muchas desventajas respecto al MP3 y pocas ventajas: en general los sonidos de las tarjetas son malos, el volumen base de los samples varia de una tarjeta a otra... Es muy difícil que te suene igual en todas las targetas y la calidad que puedes conseguir siempre está por debajo de la de un MP3 producido en estudio.
En lo del MIDI ya no te puedo ayudar, sorry ^_^
Sync :guay:
Gracias de todos modos, la verdad es que lo del MIDI solo lo queria por una razon y es que los instrumentos de piano y los de cuerda suenan muy bien en todas las tarjetas que he tenido (actualmente tengo una SB128 PCI y antes tenia una SB32) y la verdad es que hacer una composicion con piano y cuerda y encima añadirle los efectos que tu quieras con wav, pues como que podria quedar muy bien...
Lo del MP3 no ralentizaria mucho el sistema? Hace tiempo tuve una demostracion de una libreria que se llamaba BASS, creo. Estaba muy bien, lo que pasa es que era de pago, o al menos eso creo...
Saludos
Buenas... que va, apenas ralentiza... echale menos de un 5% en un ordenador de gama media (1 Ghz) pero lo mejor es que hagas algunas pruebas.
Lo del MIDI ten en cuenta que hay dos opciones:
- usar un sintetizador software (aunque hubiera soporte por hw para el midi) como el que viene con DMusic, de esa manera sabes como va a sonar sea el equipo que sea (y si no hay soporte hw, no te queda mas remedio que usar eso). Lo malo es que por software es que suena bastante cutre (creo que usan interpolacion lineal a lo cutre) aunque no se come mucho rendimiento (32 canales no creo que se coman ni un 10% en un cacharro de 1GHz...)
- Usar el hw:
ventajas: no cargas la CPU
inconvenientes: si no hay soporte hw, tendras que usar la emulacion. Si hay soporte hw, en cada tarjeta sonara distinto (por los propios samples, los volumenes de los instrumentos, efectos, etc. o sea, la implementacion por decirlo de alguna manera)
ventajas de usar MIDI: ocupa poca memoria (salvo que uses emulacion y los samples te ocupen un güe*o), pero la mayor ventaja son los cambios dinámicos en la musica (cambios de instrumentos, de secciones, etc... ¿recordais el Monkey Island 2? El iMuse en todo su esplendor...) en Midi se pueden hacer esas monerias, con WAV/MP3/etc es mas chungo y mas limitado (aunque el Monkey Island 3 lo hacia... hasta cierto punto claro)
ventajas de usar wav/mp3: poca carga de CPU, suena igual en todos los equipos, la musica suena totalmente profesional (bueno, segun quien la haga... ya me entendeis)
desventajas: ocupa mucho mas (bueno, MP3 no tanto verdad? :lengua:)
creo que una buena solucion si tienes poca memoria para la musica es hacer como en el unreal tournament, usar archivos .XM y meter un reproductor de xm en el motor. Lo malo es que vas a tener mas problemas a la hora de buscar musicos profesionales que te hagan las cosas en XM (aparte de que vas a obtener una calidad de sonido/instrumentos/etc. parecida a MIDI en resumen)
todo esto es muy por encima... además quizá habría que tener en cuenta también temas como el dolby surround y movidas de esas para la musica, no tengo ni idea de si se puede usar en el DMusic algo de eso.
Bueno, si no toma tantos recursos del sistema entonces merece la pena probar, de hecho el BASS estaba muy bien hecho, el MP3 cogia solo un 3.2% del sistema, pero claro, no se hasta que punto estaba optimizado, a lo mejor intento implementar yo algo asi y se me jode el invento :sonriendo:
Un saludo
Pues mallrat lleva bastante razón en el balance que ha hecho. Aunque me parece que softsynths que utilicen sólo interpolación lineal me parece q no deben quedar muchos (creo que lo mínimo es interpolación cúbica por SPlines para cualquier softsynth que se precie ^_^')
Yo sigo recomendándote el MP3. Hacer la música interactiva no es tanto problema en realidad (y lo digo por experiencia) y hay varios juegos en el mercado que lo hacen y funciona perfectamente (sé seguro que algunos de LucasArts de la serie Star Wars, pero ahora mismo no me acuerdo de los títulos)
Respecto a un mensaje anterior tuyo: los sintéticos de piano y cuerdas suenan mal, tanto en la SB128 (tengo 33 ordenadores con ella en el curro, lo sé bastante seguro :ojo:), como en la AWE32 como en la SBLive! que tengo en casa.
Plantéate que el sonido de cuerdas es muy muy difícil de imitar, sólo se acercan a ello los teclados Korg con tecnología MOSS.
El piano también es muy complicado imitarlo bien. Los mejores "teclados" que lo imitan, los Clavinova, Celviano y demás salen por 1800-2000€... No esperarás que una SuperSBAudigy que te cuesta poco más o menos de una décima parte suene igual, ¿verdad? ^_^'
En mi casa tengo 256Mb de muestras para imitar el piano con mi SoftSynth (el Synchrnzr) y puede llegar a sonar como el Celviano pero nunca como el Clavinova o un piano de verdad... (para eso último tengo un piano y unos micros XDDD)
El MP3 es la solución a todos tus problemas. Produces los temas en un estudio, los comprimes, adaptas los cortes de cambio y listos!
Sync :guay:
[ Este Mensaje fue editado por: synchrnzr el 2002-04-26 10:15 ]
?? ah... ok :sonriendo:
[ Este Mensaje fue editado por: Emotion el 2002-04-26 10:25 ]
(sorry, había contestado a un mensaje anterior y lo estaba editando ^_^')
[ Este Mensaje fue editado por: synchrnzr el 2002-04-26 10:18 ]
Pero para usar mp3 hay que pagar royalties (si es comercial lo que haces). Verdad?
Si esto es asi, una alternativa es Ogg Vorbis.
Hola Nelo
Y donde puedo conseguir documentacion y herramientas para poder usar ese formato del que hablas?
Un Saludo
www.ogg-vorbis.comhttp://www.xiph.org/ogg/vorbis/Por ejemplo.
No me cuesta nada ponerlo, encantado, pero de todas, yo se que tu eres un artista del google, ¿que ha pasado esta vez? :malvado:
[ Este Mensaje fue editado por: NeLo el 2002-04-26 18:55 ]
El tema de los royalties si que no lo tengo nada controlado, sorry. En realidad tengo pendiente investigarlo un poco...
Aunque... Total, si algun dia se comercializa un juego con tu motor, siempre puedes comentar el tema de los royalties para que se encargue la distribuidora, porque lo que seguro que no vas a hacer será pagarlos tú mismo, ¿no? :ojo:
Las distribuidoras no pierden un duro en balde...
Te preguntarán si es la única solución, les diras que no, pero que el wav ocupa mucho, pero les dará igual... "la pela es la pela". xD
Mmmm... ciertamente XDDD
Pos nada, les dices que el juego ocupa 4 CDs más y... jejeje ^_^'
Artista del Google? jajaja ostias pues bueno lo manejo con frecuencia, pero debe ser que me lo deje en casa :sonriendo:
No ya en serio, creo que por ahora me voy a decantar por el wav, pero con algunas tecnicas de preproceso que me ayudaran a reducirlo, como por ejemplo filtrar las frecuencias que no sean audibles por el oido humano (creo que hacen esto en el MP3, no?) y aparte someterlo a compresion basica, como ADPCM, que lo reduce a la 4ª parte... pero como te dije, mirare lo del formato y a ver que se hace...
Gracias :sonriendo:
Si lo comprimes ya no será WAV. Tampoco sabía que comprimiera tanto el ADaptivePulseCodeModulation (sé lo que es, pero no me atrae especialmente ^_^)
Pues si, o al menos cuando manejaba el Cool Edit Pro y capturaba pistas de audio (pero esto que digo va de la epoca del 486, con el Cool Edit 95, con el Cool Edit Pro es igual, solo que no me puse a medir las diferencias) las pasaba a pelo al Microsoft ADPCM y se quedaba siempre en la 4ª parte, creo que hay otro que es el IMA ADPCM o algo asi que es igual.
De todas formas, creo que en DirectSound, al declarar una estructura del tipo WAVEFORMATEX el tipo ADPCM de Microsoft esta soportado, pero no te lo puedo confirmar de modo rotundo, solo es algo que me dijeron... lo has visto tu?
Saludos
Nooo! Emotion, hazte un favor a ti mismo y a la humanidad y no uses ADPCM, efectivamente lo deja en la cuarta parte, pero se nota muchiisimo... la pérdida de calidad es bastante apreciable (a menos que uses unos altavoces cutres, claro, pero a estas alturas es inaceptable comprimir así, sobre todo teniendo el mp3).
Citar
No ya en serio, creo que por ahora me voy a decantar por el wav, pero con algunas tecnicas de preproceso que me ayudaran a reducirlo, como por ejemplo filtrar las frecuencias que no sean audibles por el oido humano (creo que hacen esto en el MP3, no?) y aparte someterlo a compresion basica, como ADPCM, que lo reduce a la 4ª parte... pero como te dije, mirare lo del formato y a ver que se hace...
El oido pilla hasta los 20KHz aprox. es decir, "calidad CD" o sea que si cortas las frecuencias altas empezaras a notarlo (en los platillos sobre todo). Hombre, no pensarias que en los CD's iban a meter frecuencias que no fueran audibles... que derroche no? :lengua:
El mp3 es mucho mas complejo, basicamente descompone la señal en frecuencias y guarda con menos bits las frecuencias que no vas a percibir porque queden enmascaradas por otras mas potentes, siguiendo un modelo "psicoacústico" (ozú).
el ogg *creo* que se puede usar libremente
el mp3 *creo* que se puede usar libremente para fines no comerciales
hay un compresor mp3 de uso totalmente libre y muy bueno: LAME
http://www.sulaco.org/mp3/
Gracias por el link, lo estudiare con detenimiento, si bien lo del MP3 me crispa un poco ya que de nada me serviria implementar en mi motor de desarrollo soporte para el si luego resulta que no voy a poder vender un juego hecho con el.. :triste:
Por cierto, mejor que usar MP3, usa vorbis OGG que es lo mismo y encima gratuito.
Es igual de rapido en procesamiento que el MP3? es decir, consume los mismos recursos o tiene el paladar mas... fino?
Es muy parecido, aunque no hecho un test con los dos formatos para poder decirlo con seguridad.
o sea, si yo me hago un descompresor de mp3 en ensamblador, ¿lo puedo usar en mis programas?, o dicho de otra forma, que decis que está protegido por copyright, el formato o el plugin para descomprimirlo....
un saludo
Hi
El formato. Luego cada descompresor puede tener una licencia, busca uno libre o hazte uno.
Byez.
Y con respecto al OGG VORBIS, si existiera algun codec (que evidentemente ha de existir, digo yo...) o filtro para DirectMedia, podria declarar en mi codigo una estructura WAVEFORMATEX donde en el tipo de formato le pudiera pasar directamente el identificador que le correspondiera al OGG VORBIS o tengo que 'masticarlo' antes para obtener un wave o algo parecido que pueda meter en un buffer?
Saludos
Respecto a tu última pregunta depende: para DirectSound tiene que ser un formato reconocido en las especificaciones estándar (PCM, ADPCM, etc...) Microsoft sólo garantiza la reproducción PCM en la especificación de las DX8.1
Si usas DirectShow (que es lo lógico) sí es como tú dices porque utiliza los filtros de DMedia para todo. Basta con tener el codec instalado. Por ejemplo, puedes reproducir pelis en DivX con el DirectShow con sólo tener el codec registrado en Windows. No debería descubrirte nada, en la documentación está todo esto que he dicho (si mal no recuerdo)
Mi motor utiliza DirectShow para reproducir MP3 en VBR, calidad CD para la BSO y DirectSound para el sonido de ambientación, si te sirve de orientación.
Por cierto, alucino con el desconocimiento sobre formatos de sonido y demás de la gente. Unas preguntas que me surgen al leer un mensaje de Mallrat:
"Nooo! Emotion, hazte un favor a ti mismo y a la humanidad y no uses ADPCM, efectivamente lo deja en la cuarta parte, pero se nota muchiisimo... la pérdida de calidad es bastante apreciable (a menos que uses unos altavoces cutres, claro, pero a estas alturas es inaceptable comprimir así, sobre todo teniendo el mp3)."
¿Cómo puede ser que utilizando ADPCM que no es ningun método de compresión de sonido (ni mucho menos con pérdida de calidad) sino un sistema de codificación, al igual que el PCM que se utiliza en los WAVs convencionales, pierda calidad?
"El oido pilla hasta los 20KHz aprox. es decir, "calidad CD" o sea que si cortas las frecuencias altas empezaras a notarlo (en los platillos sobre todo). Hombre, no pensarias que en los CD's iban a meter frecuencias que no fueran audibles... que derroche no? "
Hombre, casi ha acertado en lo de los 20KHz. El oido humano pilla frecuencias un poco más agudas, aunque con la edad se pierde la sensibilidad a éstas. Los instrumentos de metal como trombones, trompetas (y platillos, sí) es lo primero en lo que se nota.
Pero luego has metido la pata hasta el sobaco ¿me estás diciendo que en los CDs de audio en los que la información sobre la señal es PCM de 16bits cruda con dos canales se recortan las frecuencias como si de un MP3 se tratase? ¿cómo, cuándo, dónde? Es decir, según tu suposición... ¿todos los reproductores de CD descomprimen MP3?
"El mp3 es mucho mas complejo, basicamente descompone la señal en frecuencias y guarda con menos bits las frecuencias que no vas a percibir porque queden enmascaradas por otras mas potentes, siguiendo un modelo "psicoacústico" (ozú)."
Por lo menos esto lo has acertado todo, más o menos. La señal se descompone en componentes frecuenciales como tú bien dices, de las cuáles se van eliminando las que quedan enmascaradas por otras componentes más potentes en función del bitrate que se pretende. Si el bitrate es constante (CBR), eso es lo que impone el umbral recorte, si el bitrate es variable (VBR), puedes ajustar el porcentaje de señales a codificar. La observación más interesante es que mediante el VBR puedes mantener la calidad CD al 100% recortando sólo las frecuencias absolutamente imperceptibles, aún consiguiendo un buen recorte de tamaño (es lo que aprovecho en mi motor de sonido)
Venga, un saludo a todos y a ver si Emotion enseña algo de su motor, que algunos nos morimos de curiosidad :ojo:
Sync :guay:
PD: (sólo para algunos) Si no sabeis de lo que hablais, no pasa nada por decir que no teneis ni idea como hice yo sobre el tema de la patente del MP3 (vergüenza me tendría que dar no saberlo, ya lo sé ^_^') en vez de empezar a soltar chorradillas que a mi, (como profesor de acústica y de música que fui el año pasado y hasta mediados de éste) se me caen los cojones al suelo al oirlas (en otras palabras, me descojono XDDD) Lo peor del asunto es que a la persona que ha pedido información no sólo no la ayudais sino que además la desorientais.
O sea que entonces podria codificar los wave usando ADPCM habiendo previamente procesado los wave para recortarles las frecuencias inaudibles?
Si fuera asi, entonces si bastaria con declarar en el WAVEFORMATEX que el formato iba a ser MS_ADPCM (creo que era asi, pero no me acuerdo bien, ultimamente no he tenido mucho tiempo para leer o probar) y de esa manera ni siquiera necesitaria usar DirectShow, ya que seria DirectSound quien me serviria el buffer con los datos de audio... o no? :sonriendo:
De cualquier modo, tendre que leerme a fondo la documentacion de DirectX 8.0a (es la que tengo, ya que en la pagina de DirectX no esta la actualizacion para desarrolladores a la 8.1 en lo que se refiere a documentacion, a no ser que no hayan habido cambios sustanciales, sino que solo hayan corregido algun fallo que otro o hayan mejorado la manera de procesar los datos)
Un Saludo
Parte por parte:
"O sea que entonces podria codificar los wave usando ADPCM habiendo previamente procesado los wave para recortarles las frecuencias inaudibles?"
Por supuesto... que no ^_^
Veo que no estais muy puestos en el tema del sonido, ciertamente...
Los WAVs son, por defecto, PCM. Hay otros estándares dependientes del hardware de sonido del ordenador, algún otro independiente como el ADPCM...
Tanto el PCM como el ADPCM comprimen una representación del sonido en el dominio temporal. Cada muestra recoge el valor de modulación del sonido aproximado en un pulso de tiempo, en el caso del Pulse Code Modulation o la diferencia con respecto a la muestra anterior de ese valor de modulación, en el caso del ADaptive Pulse Code Modulation
Para poder eliminar las frecuencias inaudibles, necesitas convertir esa señal discreta al dominio frecuencial, por ejemplo con una Transformada Rápida de Fourier más conocida como FFT. Una vez tienes una representación en el dominio frecuencial de un cierto número de muestras (necesitas un número mínimo de muestras para reconocer una frecuencia con la FFT, cuanto más grave, más muestras) puedes obtener el espectro, es decir, el módulo de la secuencia de complejos que resulta de aplicar la FFT. Ahora del espectro podemos recortar las frecuencias inaudibles. Si queremos obtener un espectro más sencillo, podemos ir recortando las frecuencias más débiles (eso es lo que se puede ajustar en el CBR o VBR del MP3) Una vez hecho esto, podemos recodificar las bandas que nos han espectro resultante. Este proceso no lo conozco muy bien, pero si no recuerdo mal, se utiliza compresión aritmética para ahorrar espacio.
En resumen, después de todo el rollo que he soltado: el stream de un es un conjunto de chunks que describen la presencia de ciertas componentes frecuenciales de sonido, mientras que un WAV en PCM o ADPCM es una especie de vector dB/t.
Como ves no tiene nada que ver una cosa con la otra.
"Si fuera asi, entonces si bastaria con declarar en el WAVEFORMATEX que el formato iba a ser MS_ADPCM (creo que era asi, pero no me acuerdo bien, ultimamente no he tenido mucho tiempo para leer o probar) y de esa manera ni siquiera necesitaria usar DirectShow, ya que seria DirectSound quien me serviria el buffer con los datos de audio... o no?"
Como decía antes, los búferes de DirectSound sólo están garantizados para funcionar con streams PCM, aunque pueden soportar otros formatos definidos en WAVEFORMATEX pero no en todos los ordenadores. Por lo menos, es lo que pone en la documentación.
"De cualquier modo, tendre que leerme a fondo la documentacion de DirectX 8.0a (es la que tengo, ya que en la pagina de DirectX no esta la actualizacion para desarrolladores a la 8.1 en lo que se refiere a documentacion, a no ser que no hayan habido cambios sustanciales, sino que solo hayan corregido algun fallo que otro o hayan mejorado la manera de procesar los datos)"
No hay cambios relevantes
Venga, un saludo y a ver si estudiamos un poco. ¿Nadie ha hecho "Sistemas y Señales", "Proceso de Señales" en la carrera? :lengua:
Sync :guay:
[ Este Mensaje fue editado por: synchrnzr el 2002-04-30 19:19 ]
Bueno, creo que he entendido lo que me has dicho, pero has de tener en cuenta una cosa:
Lo de cribar las frecuencias inaudibles es un proceso que en ningun momento tenia pensado hacer en tiempo real, sino con la ayuda de algun software de proceso digital de sonido (incluso con algo de documentacion que tengo sobre el tema tenia pensado la posibilidad de elaborar yo mismo un programa para tal fin), es decir, a mi motor, desde mi punto de vista, y para reducir el numero de ciclos de ejecucion del mismo, solo deberian entrar a proceso aquellos datos que inevitablemente hayan de ser procesados, lo demas no entra.
Entonces, y a riesgo de parecer rematadamente tonto, volvere a insistir (pero esta vez y con casi todo aclarado, con menos fuerza :malvado:):
Si yo cogiera esa onda de sonido y eliminara esas frecuencias, una vez limpias las frecuencias que componian esa pista de audio, no puedo acaso volver a componer el wave expresandolo como un conjunto de muestras? es decir, no puedo volver a hacer una conversion o la informacion sobre la onda de sonido en si misma se pierde al hacer la conversion? y si es asi, no hay alguna manera de preservarla?
Ah, por cierto... no, no fui a clase de señales en la carrera, la verdad es que yo solo estuve 2 años en informatica superior, pero no pase en realidad del primer año, con lo que no veo posible mi asistencia a tales clases. lo siento, la cafeteria ejercia un extraño e inevitable control sobre mi :malvado:
Saludos! :sonriendo:
Wolas de nuevo, te paso la direccion de la pagina de creative con descargas para programadores aficionados:
http://developer.creative.com/LEFTMENU/DC_...M_Downloads.aspAqui tienes la openAL y el sdk de la EAX, y algunas cosas mas.
Tambien se puede conseguir el sdk profesional pero para eso tienes que pertenecer a una empresa y pedirlo por formulario. Es en esa misma web.
Buenas! vaya, este ataque en toda regla no me lo esperaba... :lengua:
synchrnzr, profesor de acústica (¿hago una reverencia?), alguna vez has programado un circuito de reverberación o de coro? alguna vez has implementado un filtro chebyshev? alguna vez has creado un algoritmo de compresión de sonido? alguna vez has hecho un algoritmo de interpolación, no lineal ni cúbica, si no de verdad (sin(x)/x) de N puntos, o has realizado un analizador del espectro, o has usado en alguna de estas dos cosas una ventana Hanning, por ejemplo?
(ahora es cuando me dices que si a todo y quedo como el culo...) :-?
"¿Cómo puede ser que utilizando ADPCM que no es ningun método de compresión de sonido (ni mucho menos con pérdida de calidad) sino un sistema de codificación, al igual que el PCM que se utiliza en los WAVs convencionales, pierda calidad? "
Cual es para ti la diferencia entre codificación y compresión en este contexto? vale, acepto el matiz, pero en cualquier caso el PCM codifica los datos sin ningun tipo de compresión, y el ADPCM los codifica con una compresión que le hace perder calidad frente al PCM. Eso es indiscutible (si conocieras un poco el algoritmo que usa lo sabrías). Es como el BMP frente al JPEG. La unica ventaja del ADPCM es que ocupa la cuarta parte que en PCM, pero pierde mucha mas calidad que por ejemplo un MP3 que ocupe la cuarta parte que el PCM, con lo cual el ADPCM me parece un sistema de compresión... sencillamente viejo.
"Hombre, casi ha acertado en lo de los 20KHz. El oido humano pilla frecuencias un poco más agudas, aunque con la edad se pierde la sensibilidad a éstas. Los instrumentos de metal como trombones, trompetas (y platillos, sí) es lo primero en lo que se nota."
vale, el oido pilla algo mas pero a partir de ahí pierde bastante. Pero a ver, para que quieres guardar más allá de los 20 Khz si luego no tienes unos auriculares o unos altavoces que lleguen "decentemente" (en muchos casos no llegan de ninguna manera) hasta los 20 Khz? Yo me he ido a la realidad, y la realidad es que ningún usuario necesita ir más allá de los 44 Khz de frecuencia de muestreo que ofrecen los CD's. Yo personalmente lo noto mas en los platillos que en las trompetas, que quieres que te diga. Si miras el espectro de ambos verás que el nivel de señal en torno a los 16-20 Khz es muchisimo mayor en los platillos que en los metales, así que es lógico que se note mas.
"Pero luego has metido la pata hasta el sobaco ¿me estás diciendo que en los CDs de audio en los que la información sobre la señal es PCM de 16bits cruda con dos canales se recortan las frecuencias como si de un MP3 se tratase? ¿cómo, cuándo, dónde? Es decir, según tu suposición... ¿todos los reproductores de CD descomprimen MP3?"
Que dices, yo no he dicho eso en ningun sitio. A ver si lees mejor las cosas colega.
"Por lo menos esto lo has acertado todo, más o menos. La señal se descompone en componentes frecuenciales como tú bien dices, de las cuáles se van eliminando las que quedan enmascaradas por otras componentes más potentes en función del bitrate que se pretende."
Hombre, eso si te parece bien? He procurado dar la explicacion mas sencilla pero comprensible posible, lo que no quiero es liar a la peña con cosas infumables.
Bueno, pues lo dicho, yo escribo intentando mantener las cosas en un grado de simplicidad comprensible para que la peña no se lie, si eso ha dañado tus oidos... es tu problema, yo se perfectamente de lo que hablo, y también me he divertido mucho leyendo tu post. Afortunadamente no se me han caido los cojones al suelo (supongo que aun estaras buscandolos) :lengua:
PD. Me encanta cada vez que pones lo que significa ADPCM porque NO es eso:
"la diferencia con respecto a la muestra anterior de ese valor de modulación, en el caso del ADaptive Pulse Code Modulation"
estas equivocado colega, ADPCM es "Adaptive Differential Pulse Code Modulation" y basicamente lo que hace es guardar la diferencia entre un valor calculado con un algoritmo de predicción y el valor real. Si no recuerdo mal usa varios coeficientes preestablecidos para almacenar esa diferencia, por eso hay varias versiones, como la de MS o la de IMA, porque cada una usa unos coeficientes distintos.
Por cierto, si tu has ido a clase como insinuas, podrías haber aprendido algo ya de paso... :malvado:
[ Este Mensaje fue editado por: mallrat el 2002-05-01 04:11 ]
Estoy de acuerdo con mallrat, synchrnzr se ha pasado un poco al contestar a los del foro, y tenga uno razon o no, lo primero es respetarse mutuamente, asi que pido que por favor no deriveis en una serie de ataques los unos a los otros, que este foro es de programacion :ojo:
Por cierto, el ADPCM que la primera vez que lo oi creia que era ADvance PCM xDD es "Adaptive Differential Pulse Code Modulation", cada letra es de una palabra, que no es un acronimo.
En cuanto a los wav, hay de muchas clases, tanto basados en ADPCM como PCM como ACM o mil cosas mas.
Por cierto, me ha surgido una duda, haber que sabeis, las directx 8 pueden reproducir mp3 por fin, se supone que si lo uso ya no tengo que pagar derechos? porque en principio seria microsoft lo que los pago no? ya me direis.. :lengua:
ta otra.
Le doy la razón a seryu. Supongo que a raiz de ciertos problemas personales he estado demasiado susceptible estos últimos días y el tono y forma en que redacté mi último mensaje no era el adecuado. Es más, tal vez era un poco insolente y prepotente y pido disculpas públicamente, en especial a mallrat (lo primero es reconocer los errores) :triste:
De todas formas, mallrat, aunque tu último mensaje tampoco está exento de dichos defectos, responderé tus preguntas con calma, sin ninguna intención de ofenderte nuevamente ni de que este mensaje desemboque, como seryu decía, en una especie de "pique" o algo por el estilo. Antes que ello, prefiero dejar de escribir en el foro y, si creeis que es mejor así, lo haré. La verdad es que dedico a este foro un tiempo que no tengo sólo para intentar ayudar, pero si en vez de ello estoy entorpeciendo el foro, me lo podeis decir abiertamente y lo aceptaré sin ningún problema ni mal rollo. Prefiero la sinceridad, aunque a veces no guste y pueda no gustarme a mi.
alguna vez has programado un circuito de reverberación o de coro? Sí, en ensamblador de Intel, C, C++, Pascal y ensamblador ARM7TDMI para GameBoy Advance.
alguna vez has implementado un filtro chebyshev? En C y en ensamblador de Intel.
alguna vez has creado un algoritmo de compresión de sonido? Propio no. Sí he programado algoritmos basados en el VBR del MP3.
alguna vez has hecho un algoritmo de interpolación, no lineal ni cúbica, si no de verdad (sin(x)/x) de N puntos, o has realizado un analizador del espectro, o has usado en alguna de estas dos cosas una ventana Hanning, por ejemplo?
Sí por la interpolación lineal, cúbica y por splines, sí por el espectrógrafo, y no por la ventana de Hanning.
(ahora es cuando me dices que si a todo y quedo como el culo...)
Te ha ido de poco... :ojo: De todas formas, tampoco hubieras quedado mal, en mi opinión. Parece que soy yo el que ya ha quedado como el culo, dejémoslo así.
Cual es para ti la diferencia entre codificación y compresión en este contexto?
Llamo codificación a la mera representación digital del señal analógico y compresión al cambio de representación realizado para reducir el espacio o tiempo de proceso de la representación obtenida del muestreo. Admito que en general se admite la ambigüedad de ambas cosas.
vale, acepto el matiz, pero en cualquier caso el PCM codifica los datos sin ningun tipo de compresión, y el ADPCM los codifica con una compresión que le hace perder calidad frente al PCM. Eso es indiscutible (si conocieras un poco el algoritmo que usa lo sabrías). Es como el BMP frente al JPEG. La unica ventaja del ADPCM es que ocupa la cuarta parte que en PCM, pero pierde mucha mas calidad que por ejemplo un MP3 que ocupe la cuarta parte que el PCM, con lo cual el ADPCM me parece un sistema de compresión... sencillamente viejo.
La verdad es que puede hacer años (como 5, si cabe) que toqué el ADPCM y aún entonces no me atraía mucho. Tienes razón en lo de las siglas, olvidé el Differential que va en medio. Respecto al algoritmo, recuerdo que en mis implementaciones los intervalos/diferencias que utilizaba siempre eran exactos, y por tanto no había pérdida de calidad, pero ahora mismo no recuerdo que hubiera utilizado ningún algoritmo de predicción. Ante la posibilidad de que lo que dices sea cierto en alguna de las distintas implementaciones, te doy la razón.
vale, el oido pilla algo mas pero a partir de ahí pierde bastante. Pero a ver, para que quieres guardar más allá de los 20 Khz si luego no tienes unos auriculares o unos altavoces que lleguen "decentemente" (en muchos casos no llegan de ninguna manera) hasta los 20 Khz? Yo me he ido a la realidad, y la realidad es que ningún usuario necesita ir más allá de los 44 Khz de frecuencia de muestreo que ofrecen los CD's. Yo personalmente lo noto mas en los platillos que en las trompetas, que quieres que te diga. Si miras el espectro de ambos verás que el nivel de señal en torno a los 16-20 Khz es muchisimo mayor en los platillos que en los metales, así que es lógico que se note mas.
Empezaré por detrás. Yo no dije que se notara más en trompetas, trombones, etc... que en platillos, dije que se notaba especialmente en instrumentos de metal. Por supuesto que el nivel de agudos de los platos (que son instrumentos de metal) es mucho mayor que el de los citados instrumentos de viento. Yo lo noto en ambos, por lo menos. Supongo que, como músico, estoy más acostumbrado a oir los intrumentos reales. No voy a entrar a discutir en la calidad los auriculares/altavoces que pueden tener los usuarios. En lo que dices que la calidad de CD es más que suficiente para cualquier usuario, estoy totalmente de acuerdo.
Es lo que dices al principio del párrafo que me deja algo confuso y lo que relaciono que esta frase de tu otro mensaje "Hombre, no pensarias que en los CD's iban a meter frecuencias que no fueran audibles... que derroche no?" que por cierto enlaza con tu "Que dices, yo no he dicho eso en ningun sitio. A ver si lees mejor las cosas colega."
Siempre intento leer todo con la máxima atención. Si tienes los conocimientos de los que presumes, me extraña mucho que digas eso, pero como ya he dicho antes, mi intención en este post no es en absoluto ofenderte ni poner en duda tus conocimientos como hice en el anterior. En realidad, me gustaría que me explicaras cómo se hace para eliminar las frecuencias inaudibles antes de grabar los CDs y cómo consigues ganar espacio con ello. Ya sé que no has dicho que se gane espacio, pero si dices que es un derroche meter frecuencias inaudibles en un CD ¿por qué lo es?
Por mi lado, lo único que puedo decir, basándome en mis humildes conocimientos sobre teoría del muestreo, que en una señal muestreada a 44100Hz existen señales de hasta 22050Hz de frecuencia (la mitad de la frecuencia de muestreo), por tanto contiene tanto ultrasonidos de más de 20KHz como infrasonidos de frecuencia muy inferior a 1Hz, dependiendo de la duración del señal muestreado. También creo saber que en los CDs se graba la información de la digitalización en PCM crudo. Y no sé más.
Si no estoy muy equivocado en lo anterior, no veo posible que el hecho de no guardar señales de frecuencias inaudibles (de todas formas, es imposible por el aliasing, que no existan señales de esas frecuencias) aún con un preproceso sobre la señal PCM pueda llevar a ahorrar espacio o lo que sea. Lo siento, sólo llego a eso y lo reconozco humildemente. ¿Qué desconozco o he pasado por alto?
Hombre, eso si te parece bien? He procurado dar la explicacion mas sencilla pero comprensible posible, lo que no quiero es liar a la peña con cosas infumables.
Bueno, pues lo dicho, yo escribo intentando mantener las cosas en un grado de simplicidad comprensible para que la peña no se lie, si eso ha dañado tus oidos... es tu problema, yo se perfectamente de lo que hablo, y también me he divertido mucho leyendo tu post. Afortunadamente no se me han caido los cojones al suelo (supongo que aun estaras buscandolos)
Por cierto, si tu has ido a clase como insinuas, podrías haber aprendido algo ya de paso...
Eso me parece muy bien. Si te lees la mayoría de mensajes que he escrito, (excepto el anterior a éste) creo que no eran demasiado técnicos ni complicados. Éste lo es un poco más porque va dirigido a ti, principalmente, que parece que dominas el tema, que has aprendido algo en las clases y sabes manejarte con el lenguaje técnico. Por cierto, yo intento saber de lo que hablo también. Me alegro que te divirtieras leyéndolo, esa era mi intención ^_^
Ya cambiando de tema: las cuestiones de seryu me parecen muy interesantes. Con las DirectX, aún en versiones anteriores, ya se podía reproducir MP3. Pienso como tú, que si utilizas los codecs propios de Windows no deberías pagar royalties, aunque la duda me surge cuando pienso que los archivos MP3 están comprimidos con esa tecnología. Estoy esperando información, pero aún no he recibido respuestas. Si alguien sabe algo al respecto y quiere arrojarlo ya en el foro...
Sync :guay:
PD: Se me olvidaba responderle al pobre de Julio.
El problema que tiene hacer lo que tú dices es que al recodificar el WAV de nuevo tendrás el mismo número de muestras, por tanto el fichero te ocupará el mismo espacio y tendrás que procesar lo mismo, o sea que no ganas nada. Es más, perderías calidad inútilmente.
Lo máximo que podrías hacer es tener los efectos de sonido en MP3 y luego decodificarlos al cargarlos en memoria, antes de utilizarlos. Lo que no te saldrá a cuenta nunca es tener los sonidos en MP3 en memoria y descomprimirlos y mezclarlos a tiempo real, ahí sí puedes perder mucho tiempo de proceso.
(Después de todo lo dicho, hablo como ignorante, claro :lengua:)
Por cierto, a mi también me atrae la cafetería, ya pasa... ^_^' Lo que decía de las clases no iba por ti de ningún modo, aunque nunca van mal... :ojo:
[ Este Mensaje fue editado por: synchrnzr el 2002-05-02 13:23 ]
Creo que me he equivocado de nuevo. En las preguntas sobre interpolación ¿te referías a un filtro convolutivo, basado en la convolución con una sinc, verdad (por eso ponías lo del sin(x)/x)? En ese caso, lo he implementado en C. También lo implementé para ensamblador de ARM7TDMI (GameBoy Advance) Aunque optimizándolo al máximo, necesita demasiado tiempo de proceso para esa máquina y tuve que quitarlo ^_^'
[ Este Mensaje fue editado por: synchrnzr el 2002-05-02 18:08 ]
Vaya, ahora si que estoy mas liado que la pata de un romano... jarrll... :sonriendo:
En fin, la verdad es que algo si he sacado en claro (espero no haberme hecho la picha un lio) y es que deberia usar otro formato que no sea el ADPCM, no?
La verdad es que imagine que al reducir el fichero una cuarta parte y eliminando las frecuencias inaudibles (o las mas debiles) conseguiria reducir el espacio mas, pero claro, si hay que tener en cuenta la posibilidad de que determinados espectros se repitan a lo largo de una muestra, entonces creo que tal vez deberia usar otro formato, lo que pasa es que quiero que entendais algo, y es lo siguiente:
Yo quiero esto para implementar sonido en mi motor, el cual estoy desarrollando para fines comerciales (quiero hacer juegos comerciales con el), por lo que el formato que escoja debe estar libre de royalties (a no ser que los royalties sean infimos o no sean EN TOTAL muy prohibitivos, si bien prefiero la via gratis total :sonriendo:).
Lo que si tengo decidido es que la API sera DirectSound, ya que asi me aseguro que va a funcionar en todos los PCs (que usen Windows, naturalmente), aunque me quedan por saber unas cuantas cosas, como por ejemplo el nivel del calidad o de potencia (me refiero a la calidad de la simulacion) de DirectSound3D (tenia entendido que las APIs de EAX y A3D salieron al mercado como una manera de sustituir la programacion con DirectSound3D porque decian que no era muy bueno, aunque me gustaria que me lo confirmarais)...
Otra cosa que me intriga es el hecho de que, segun me han dicho, si utilizo DirectMusic para la musica tengo que organizar mi pista de audio en segmentos (o algo asi), de forma que si quisiera pasar de una pista de audio a otra seria facil mediante segmentos, lo que pasa es que ahora mismo no soy capaz de imaginar como podria hacer lo de los segmentos o como podria organizar los datos de manera que las pistas de audio encajaran en segmentos
De todos modos, me gustaria saber si vosotros habeis probado lo de los segmentos y el sonido en 3D :sonriendo:
Gracias y perdon por el interminable toston :sonriendo:
P.D. para sync: tio pagaste los 6000$ que dicen que cuesta el kit de desarrollo para el micro de la GBA???
_________________
Julio Meca
ALPHA SOFTWARE
[ Este Mensaje fue editado por: Emotion el 2002-05-02 18:13 ]
Lo siento, no quería liarte con el mensaje anterior. En resumen: como bien dices, no utilices ADPCM (almenos en eso nos ponemos todos de acuerdo ^_^') Sobre lo que dices de reducir el espacio y demás en el segundo párrafo no diré nada más ya porque veo que debo explicarme muy mal: amplia tus conocimientos con documentos oficiales o libros, aprenderás mucho más que en los foros ^_^
Lo que dices del DirectSound, me gustaría poder compararlo con los SDKs del A3D y el EAX para poder contestare con más precisión. Sólo puedo decirte que no he echo nada de menos en el DirectSound (la velocidad del sonido tal vez, que la tuve que emular "a mano" y alguna cosilla más, pero poco) y su simulación 3D es suficientemente buena en mi opinión. No mencionaré los algoritmos de simulación que utiliza, no sea que me tachen de complicar los mensajes inútilmente u ofenda a alguien (me siento censurado, en cierto modo...) pero están los más importantes y creo que son suficientes. Yo lo utilizaría. Bueno, lo utilizo, de hecho :ojo:
De DirectMusic te diría que una opción es utilizar meta-eventos marcadores para marcar los segmentos, pero cómo no he tocado el tema casi nunca (ni pienso hacerlo) dejaré que alguien dé una mejor solución.
Por cierto: no es necesario comprar el kit oficial para programar GameBoy Advance. Por supuesto que no he pagado nada por el SDK ni del micro ni de la AGB, existen varias alternativas a ello.
Un saludo
Sync :guay:
PD: ¿Cómo puedes disculparte por el tostón del mensaje después del post tipo "Quijote" que he puesto? XDDD
Bueno, he aquí un par de definiciones del ADPCM sacadas de manuales oficiales:
"Adaptive Differential Pulse Code Modulation; encoding technique, standardized by the CCITT, that allows an analog voice conversation to be carried within a 32k-kbit/s digital channel; 3 or 4 bits are used to describe each sample, which represents the difference between two adjacent samples. Sampling is 8,000 times a second."
"A variation of pulse code modulation (PCM) that only sends the difference between two adjacent samples. This produces a lower bit rate and is sometimes used to effectively compress a voice signal, allowing both voice and digital data to be sent where only one would normally be sent."
Bueno, pues ya me he remirado un poco el tema para satisfacerte, mallrat. A ver si esto te convence más:
La calidad del ADPCM estándar es debida a la cuantización y muestreo de la señal, al igual que la calidad del PCM.
No es porque realice ningun tipo de compresión sobre una señal previamente muestreada: el ADPCM es un método de codificación como ya dije y la calidad deriva directamente de los parámetros de muestreo y no de ningun tipo compresión.
En el caso del estándar del CCITT es lógico que la cálidad sea baja porqué utiliza 3 o 4 bits por diferencia y el muestreo es a 8000Hz, pero no sólo se pueden utilizar esos parámetros en ADPCM. Entendería que me dijeras que un WAV pierde calidad al recodificarlo en el ADPCM estándar del CCITT. Es lo mismo que si me dices que una pista de CD la recuantizas a 11025Hz y 8 bits y pierde calidad. ¿Acaso la pierde por el hecho de estar codificado en PCM? Piénsalo bien ¿en ADPCM de 16bits a 44100Hz qué pérdida de calidad hay en relación a la correspondiente representación PCM de 16bits 44100Hz? Ninguna. De hecho, aunque no voy a hacer la demostración aquí, incluso se puede conseguir mayor calidad. Reitero: el ADPCM no se puede entender como un sistema de compresión. Y aun es menos concebible que sufra pérdida de información.
Una vez más: no quiero poner en duda los conocimientos ni la reputación de nadie, pero sigo creyendo, mallrat, que deberías repasar un poco el tema porque lo del algoritmo de predicción que tú dices no lo he visto en ninguna especificación ni lo recuerdo remotamente (sí recuerdo bien lo demás y creo que no me he equivocado en nada) Créeme que no te lo digo con ninguna mala intención. Tal vez es que debo tener algo de vocación de profe... (aunque no me gusta mucho serlo ^_^)
También espero que este mensaje te parezca suficientemente respetuoso y no te me tires al cuello como en tu otro mensaje :ojo:
Lo último que voy a intentar aclarar, a todos en general, es un problema conceptual:
ADPCM, ACM, PCM,... son representaciones en el dominio temporal. Los streams de MP3, VQF,... son representaciones en el dominio frecuencial.
Ningún tipo de compresión en el dominio frecuencial sirve para reducir la cantidad de información en el dominio temporal y viceversa.
Lo que tú decías, Julio, de eliminar bandas de frecuencias de un WAV y volverlo a codificar en WAV, ya sea en PCM, ADPCM, ACM o cualquier otra representación temporal de las decenas que soporta la estructura WAVEFORMATEX: si tienes 1 segundo a 44100Hz 16 bits, el fichero te ocupará 1 * 44100 * 2 = 88200 bytes + cabecera tanto si le has recortado las frecuencias inaudibles como si no.
Vaya, es que me gustaría, por lo menos, que entendiérais que no os sirve para nada comprimir en el dominio frecuencial para volver a pasárlo a temporal. Es lo mismo que pasar un WAV a MP3, 128kbps y volverlo a descomprimir: no sirve de nada solo pierdes calidad.
En fin, se me está acabando el afán de haceros entender un poco el tema, especialmente al ver que el esfuerzo que me supone no es bien recibido. La verdad es que me arrepiento de haber vuelto a escribir un mensaje tan largo (especialmente porque tengo unas prácticas de Robótica para mañana y con haberme enrollado tanto, ya no las acabo ^_^') Simplemente, no lo volveré a hacer. Si alguien tiene interés, que lo diga y le explico lo que quiera por mail. A partir de ahora, en el foro, sólo responderé preguntas que me hagais directamente.
Aprovecho para recomendar a todos que si necesitais información, vayais a buscarla a los sites, manuales técnicos y libros oficiales, que esos seguro que no se equivocan y no en los foros.
Sync :guay:
PD: Por cierto: haciendo balance ahora que me quedan 1 o 2 años para terminar la carrera, la verdad es que no he ido a demasiadas clases en la Uni, o sea que no habré aprendido mucho en ellas... ^_^'
Synchnz, eres un picao. Pero si no tienes ni idea!!!!!
Ya tenías que salir por medio XDDD
Bueno, no todo es tan complicado en la vida. Os recuerdo que podeis reproducir MP3 con DirectX 8( DirectShow concretamente).
Este topic me deja loco a veces.
Vale, entonces la cosa se queda en que se puede reproducir el MP3, pero vuelvo a insistir... hay que pagar por utilizar MP3 en un juego comercial? es que a mi, por ahora, si hay que pagar, no me sirve... tiene que ser algo que sea totalmente gratuito y sin royalties ni ningun impuesto de ninguna clase...
Como ya dije...
Si usas mp3, debes pagar.
Concretamente, creo que debes pagar royalties por cada copia vendida, aunque no se si seguirá siendo asi.
Por cada copia del juego o por cada pista de audio que lleve el juego?
Por cada copia vendida. La cantidad o porcentaje por copia no lo se, quizas dependa de los archivos mp3 que use.
Ay... porque tengo la sensacion de que voy a acabar pagandole la universidad de los niños a la gente del Fraunhofer Insitute (eran estos los del MP3, no?) y los de la SGAE??
Seran cosas mias... :malvado:
Y vuelvo a repetirme...
Una alternativa a mp3 es OGG Vorbis.
www.vorbis.com
Si, lo he visto... aunque aun tengo que leerme las cosas que salen en la pagina, lo que pasa es que cuando lei que estaba hecho con licencia GPL me vine un poco abajo, ya que segun tengia entendido (puedo estar equivocado y algo me dice que asi es...) el codigo bajo licencia GPL se podia obtener gratis pero no podias sacar beneficios con el, o eso era con la LGPL... creo que me estoy haciendo la picha un lio... :sonriendo:
What licensing applies to the Ogg Vorbis format?
The OggVorbis specification is in the public domain. It is completely free for commercial or noncommercial use. That means that commercial developers may independently write OggVorbis software which is compatible with the specification for no charge and without restrictions of any kind. However, developers that wish to use the open source software we have written must adhere to certain rules.
okis, tomo nota...
Para ahorrarte curro buscando, Julio (sacado del FAQ de Vorbis igual que el párrafo de NeLo y con lo más importante resaltado, espero que te sea de utilidad)
The bundled OggVorbis utility software is released under the terms of the GNU GPL, or GNU General Public License. The details can be found at http://www.gnu.org.The libraries and SDKs are released under the more business friendly BSD license. Please note that developers are still free to use the specification to independently write closed-source implementations of OggVorbis which are not bound by these licenses.Sync :guay:
[ Este Mensaje fue editado por: synchrnzr el 2002-05-03 18:52 ]
Ah, o sea que para poder usar el ogg vorbis no me tengo que preocupar por el tema de licencias, solo en el caso de utilizar el software que ellos te dan, no?
Pues entonces creo que me decantare por el, a ver si me va bien :sonriendo:
Muchas gracias a los dos :sonriendo:
Mientras no hagas nada open source no, como has podido leer ^_^
¿PERO CÓMO VA A HABER QUE PAGAR POR USAR UNA FUNCIÓN DE DIRECTSHOW?
No se, pero yo creo que es totalmente lícito y legal reproducir mp3 a traves del directshow y no tener k pagar nada a microsoft por usarlo. (en caso contrario nos lo dejarían clarito en la sdk)
¿o es k ahora hay k pagar por usar directx?
faltaría mas..
si alguien no está del todo seguro pues que contacte con mocosoft y k les pregunte
pero supongo que una cosa es utilizar DirectShow y otra muy distinta el formato que le pases a DirectShow... pero como no estoy seguro, pues no lo afirmo...
Al fin y al cabo, y como bien sabras, Microsoft se suele lavar las manos con estas cosas (joder si sus manuales de software quedarian mejor en la estanteria de un abogado que en nuestras casas!!) :riendo:
Yo creo que es el problema es usar los archivos en MP3 como muy bien decía NeLo, no usar DirectShow. De todas formas he enviado un mail al Fraünhofer pa salir de dudas, pero creo que me diran lo que NeLo... snif, snif... :triste:
Sync :guay:
La licencia sobre el uso del MP3 la podeis encontrar
aquí.
¡Coño! Esto se agradece. Me ha costado un poquillo ver las tarifas para videojuegos:
Running Royalty
mp3PRO · US$ 3 750.00 per title
mp3 · US$ 2 500.00 per title
Minimum Royalties
not applicable
Note: No license fees are due if less than 5 000 copies of a particular game title are distributed.
Mmmm... malditos chupasangres...
Por lo menos si vendes pocos juegos no te roban. Y pagas por título que no por unidad... bueno, podría se peor ^_^'
¡Gracias!
Sync :guay:
Buenas! esto empieza a ser un poco aburrido, así que me enrollaré lo menos posible.
(evidentemente esto va dirigido a SYNC... y no me voy a tirar al cuello, bueno quizá un poco :lengua:)
"Hombre, no pensarias que en los CD's iban a meter frecuencias que no fueran audibles... que derroche no?"
Me refiero a que samplean a 44Khz para cubrir sólo las frecuencias audibles, no me refería a que quitaran frecuencias por debajo de los 22Khz, eso sería inutil guardando los datos en PCM.
En cuanto a lo del ADPCM, a ver... si tu codificas una señal en ADPCM a 44Khz/16 bits vas a tener la misma calidad que en PCM a 44Khz/16bits, pero estabamos hablando de reducir a la cuarta parte, y en ADPCM a 44Khz/4 bits la distorsión es perfectamente audible y un poco molesta.
Efectivamente, en el ADPCM los datos "representan" la diferencia entre dos muestras, pero que te hace pensar que es simplemente la resta aritmética de las dos? que yo recuerde se usan varios coeficientes y se usa una escala no lineal, si no como vas a guardar en 4 bits diferencias de +/- 14 bits? (digo 14 bits porque creo que ese era el rango dinámico usado en el ADPCM estándar, pero seguramente habrá variaciones para todos los gustos)
"Reitero: el ADPCM no se puede entender como un sistema de compresión."
El MP3, JPG, ZIP, etc. son sistemas de codificación o de compresión? No tiene porque ser una cosa o la otra por mucho que te empeñes. Todos son sistemas de codificación puesto que representan alguna información, pero para mi el ADPCM y los demas son también sistemas de compresión porque están pensados para comprimir información.
"Y aun es menos concebible que sufra pérdida de información."
Salvo el ZIP todos los demas pierden información. Si no entiendes eso no es mi problema. Intenta usar el ADPCM de forma que ocupe MENOS que el PCM sin perder calidad frente a éste. No se puede, y tampoco te voy a hacer la demostración.
"Tal vez es que debo tener algo de vocación de profe..."
"En fin, se me está acabando el afán de haceros entender un poco el tema, especialmente al ver que el esfuerzo que me supone no es bien recibido"
Me parece estupenda tu vocación de profe, pero eso no significa que tu sepas de lo que hablas y los demás no... y de paso te recuerdo que fuiste tu el que se tiró a mi cuello.
Espero que esto no se convierta en algo personal (y si es así y hay que luchar, que sea a vida o muerte, eh? mariconadas las minimas :lengua:)
Sí es aburrido, sí ^_^
Buenas! esto empieza a ser un poco aburrido, así que me enrollaré lo menos posible.
(evidentemente esto va dirigido a SYNC... y no me voy a tirar al cuello, bueno quizá un poco )
Como quieras...
Me refiero a que samplean a 44Khz para cubrir sólo las frecuencias audibles, no me refería a que quitaran frecuencias por debajo de los 22Khz, eso sería inutil guardando los datos en PCM.
Pos fale
En cuanto a lo del ADPCM, a ver... si tu codificas una señal en ADPCM a 44Khz/16 bits vas a tener la misma calidad que en PCM a 44Khz/16bits, pero estabamos hablando de reducir a la cuarta parte, y en ADPCM a 44Khz/4 bits la distorsión es perfectamente audible y un poco molesta.
Pos fale (bueno, para reducir a la cuarta parte la calidad de CD tendrías que codificar a 14 bits, pero bueno...)
Efectivamente, en el ADPCM los datos "representan" la diferencia entre dos muestras, pero que te hace pensar que es simplemente la resta aritmética de las dos? que yo recuerde se usan varios coeficientes y se usa una escala no lineal, si no como vas a guardar en 4 bits diferencias de +/- 14 bits? (digo 14 bits porque creo que ese era el rango dinámico usado en el ADPCM estándar, pero seguramente habrá variaciones para todos los gustos)
Hombre mira, los 14 bits han salido por otro lado... en fin, dejémoslo XDDD
El MP3, JPG, ZIP, etc. son sistemas de codificación o de compresión? No tiene porque ser una cosa o la otra por mucho que te empeñes. Todos son sistemas de codificación puesto que representan alguna información, pero para mi el ADPCM y los demas son también sistemas de compresión porque están pensados para comprimir información.
Ya te dije que no te discutiría el tema porque es ambiguo.
Salvo el ZIP todos los demas pierden información. Si no entiendes eso no es mi problema. Intenta usar el ADPCM de forma que ocupe MENOS que el PCM sin perder calidad frente a éste. No se puede, y tampoco te voy a hacer la demostración.
Por Dios! Dejémoslo... lo que tu digas...
Me parece estupenda tu vocación de profe, pero eso no significa que tu sepas de lo que hablas y los demás no... y de paso te recuerdo que fuiste tu el que se tiró a mi cuello.
Sí, ya me disculpe por mi "agresividad" que yo recuerde. Y mirándolo mejor, no tengo demasiada vocación, me falta paciencia ^_^'
Espero que esto no se convierta en algo personal (y si es así y hay que luchar, que sea a vida o muerte, eh? mariconadas las minimas)
Q bruto XDDD
Nah, paso de piques, haz lo que quieras. Doy por muerto el tema.
Venga, un saludo
Sync :guay:
Bueno, la verdad es que 2500$ por juego no esta mal, en el fondo creia que seria mas, lo que pasa es que... si, la verdad es que si, se pasan un pelo... pero oye peor es lo que he visto esta mañana... el link a la pagina de Liquid Motion... mira el precio que tiene el sistema de animacion...
Y dime si no es para morirse... :sonriendo:
Hombre... no sé cómo lo has mirado pero... ¿no es más barato licenciarse el Liquid que el MP3? :agh:
500$ menos por juego y también puedes sacarte una licencia para todos los juegos que vayas a hacer por 8000$ a precio fijo. Tampoco me extraña mucho que la superlicencia valga 25000$ porque si te da derecho a dar licencias a otras compañías... ya es mucho derecho... XD
Lo que sí veo un poco mal es la Hobbyist License por $100. Aunque supongo que si alguien es muy aficionado, a lo mejor se los gasta...
No sé, de todas formas son precios de aquellos que paga una compañía a otra y a los programadores nos da igual, más o menos, ¿no? XDDD
"Pos fale (bueno, para reducir a la cuarta parte la calidad de CD tendrías que codificar a 14 bits, pero bueno...)"
juas! lo llevas claro