Créer un format audio

Version imprimable

24/06/2016, 02h35
Cfass

Créer un format audio
Bonjour tout le monde, je m'en sors pas trop mal en programmation et là j'ai un projet personnel assez complexe alors j'aimerais avoir des conseils et suggestions de pros qui peut-être sont passés par le même sujet.

Voilà :

Je voudrais créer un algorithme de lecture et de conversion audio personnel afin d'aboutir à un format audio (je l'appelerai ".cfass") tout comme les mp3, wav, wma.

Il me faudra par exemple :
- Un logiciel qui, lui, sera chargé de convertir un son d'un autre format comme le mp3 vers mon format (.cfass)
- Un autre qui me permettra, lui, de lire tout fichier de mon format .cfass
Je ne suis pas très très fort mais je fais souvent beaucoup de recherches et pour ce sujet qui est assez complexe à mon avis, j'avais souhaité d'abord demander à tout ceux qui m'ont précédé afin de voir ce qu'ils en pensaient.
Je compte développer le logiciel de lecture en mobile (Android) puis desktop (Java), là sont mes préférences mais je reste ouvert à d'autres propositions.

Ainsi,que me conseillez-vous de faire? Vos réponses seront précieuses pour moi.

Merci d'avance.
24/06/2016, 06h22
Flodelarab

Bonjour :coucou:

Tu as parlé de tout sauf de l'essentiel: la raison d'être du format.

wav est le son brut.
mp3 a été inventé (et ses prédécesseurs) pour fournir le même fichier, mais moins lourd, car compressé.
wma a été inventé par Microsoft pour facturer une chose que les autres font naturellement et gratuitement.

C'est encore plus foisonnant si on parle des formats d'images.

Est-il indiscret de demander pourquoi (ou pour quoi) tu crées ce format ?
24/06/2016, 12h55
Cfass

Ok, en fait, je veux créer ce format dans le but d'imposer l'utilisation de mon logiciel pour la lecture de tout fichier audio que j'aurai produit.
Ainsi, le fait de passer par VLC ou Winamp ou tout autre logiciel de lecture supportant plusieurs formats ne marcherait pas quoi.
Je ne sais pas si c'est assez clir pour vous.
24/06/2016, 15h45
dourouc05

:salut:

Citation:

Envoyé par Cfass

Je compte développer le logiciel de lecture en mobile (Android) puis desktop (Java), là sont mes préférences mais je reste ouvert à d'autres propositions.

Mauvaise idée, pour moi : crée-toi une bibliothèque pour lire/écrire les fichiers dans ton format propriétaire, que tu appelleras à gauche ou à droite selon tes besoins (comme libflac, libogg, lamelib). Probablement en C ou en C++, d'ailleurs, c'est rare d'avoir ce genre de fonctionnalités en Java.

Quels sont réellement tes objectifs ? Un format qui promeut la qualité peu importe le poids, la compression peu importe la qualité, un mélange plus équilibré ? Ça te donnera déjà une idée de base sur les techniques possibles, d'algorithmes à comprendre et à implémenter…

Maintenant, si ton objectif est "simplement" d'empêcher la lecture par un autre logiciel, pourquoi ne pas repartir de l'existant et d'ajouter une couche de chiffrement, par exemple du MP3 mais ne le transmettre qu'avec du chiffrement ? Ton logiciel se chargera d'intégrer une bibliothèque de chiffrement et une autre de lecture audio. C'est grosso modo le principe de fonctionnement de certaines techniques de DRM.

Dans tous les cas, si tu crées un format propriétaire ou du chiffrement, si le contenu est intéressant, des gens se chargeront probablement de faire une implémentation libre (pense aux DVD et Blu-Ray, dont les protections ont été cassées). Aussi, si tu ennuies fortement tes utilisateurs avant de lire ton contenu, ils ne viendront probablement pas… Ne te fais pas d'illusions à ces niveaux-là.
25/06/2016, 12h52
Sve@r

Citation:

Envoyé par Cfass

Ok, en fait, je veux créer ce format dans le but d'imposer l'utilisation de mon logiciel pour la lecture de tout fichier audio que j'aurai produit.
Ainsi, le fait de passer par VLC ou Winamp ou tout autre logiciel de lecture supportant plusieurs formats ne marcherait pas quoi.
Je ne sais pas si c'est assez clir pour vous.

Bonjour

C'est super clair. Et aussi une super mauvaise idée. Si tu regardes bien sur le net, en dehors de trucs vraiment spéciaux, tout ce qui est plebiscité par les geeks, c'est justement tout ce qui est ouvert/libre. Les outils GPL font fureur. Ca fait bien longtemps par exemple que j'ai remplacé Nero cracké par CDBurnerXP et que quand je propose une solution bdd (même demandant des garanties de haute disponibilité) c'est Postgres qui me vient en tête.

Si tu veux juste créer un format plus restreint que les formats ouverts, et sans rééelle plus value, ben pourquoi alors irait-on vers ce format ??? Personne n'irait volontairement s'enfermer dans une prison dont il n'a pas la clef.

T'as pensé à l'envers. Au lieu de penser "j'invente un truc utile puis je tente d'en tirer profit", tu penses "j'invente un truc pour mon profit puis ensuite j'essayerai de le rendre utile"...
01/07/2016, 04h32
Cfass

Merci pour vos réponses, particulièrement celles de dourouc05 et Sve@r.

Citation:

Maintenant, si ton objectif est "simplement" d'empêcher la lecture par un autre logiciel, pourquoi ne pas repartir de l'existant et d'ajouter une couche de chiffrement, par exemple du MP3 mais ne le transmettre qu'avec du chiffrement ? Ton logiciel se chargera d'intégrer une bibliothèque de chiffrement et une autre de lecture audio.

Dourouc05, je crois bien que cette solution me correspond mieux. Que je comprenne, tu me proposes là de retoucher l'algorithme des fichiers MP3 ou juste de chiffrer les fichiers MP3 (produits finis) eux-même avant de les transmettre?

J'avais pensé à cette solution en premier. Sauf qu'en faisant cela le fichier chiffré était completement illisible.

Si je ne me trompe pas, les fichiers MP3 sont enregistrés en binaire : j'ai essayé de les lire avec du code java (lecture binaire), celà marche sans PB.
Alors, ayant vu cela, j'ai donc tout simplement voulu transposer le contenu d'un même fichier mp3 dans un autre (faire une copie) juste pour tester mais déja la taille du fichier obtenu n'avoisinait même pas celle du fichier original et du coup c'était illisible sur un lecteur audio.
01/07/2016, 08h14
dourouc05

Je pense plutôt à chiffrer tout le fichier d'un coup — si tu fais autre chose, tu perds toute compatibilité avec les lecteurs MP3 existants (à moins de ne chiffrer que certaines sections du fichier MP3 ? ça a l'avantage qu'on ne connaît alors pas le moindre bit du message déchiffré, ce qui rend les attaques plus difficiles, mais c'est assez théorique comme avantage…).

Citation:

Envoyé par Cfass

Si je ne me trompe pas, les fichiers MP3 sont enregistrés en binaire : j'ai essayé de les lire avec du code java (lecture binaire), celà marche sans PB.

Oui, c'est du binaire. Si tu l'écris à la hussarde, ça ne peut plus fonctionner (ou alors avec de la poudre verte !). Si tu n'arrives plus à relire les fichiers en sortie, c'est que ton code Java a des problèmes, auquel cas tu ferais mieux de te diriger vers les forums Java.
01/07/2016, 11h19
anapurna

salut

tous les fichier son binaire mais pour chaque fichier il y a des méthode de lecture et d’écriture différente
pour un fichier texte la concaténation de fichier ne pose aucun problème car celui-ci est en lecture directe
par-contre tout les fichiers tels que ce de musique ou autre on un format particulier avec souvent un entête
avec quelques informations

par exemple pour le mp3 tu as ce que l'on appelle des TAG qui sont de cette forme

_TAGID3V1 = record
Header: array[0..2] of Char;
Album, Artist, Title: array[0..29] of Char;
Year: array[0..3] of Char;
Comments: array[0..28] of Char;
Track, Genre: Byte;
end;

ensuite tu as des FRAMES
pour chaque frames tu as sa longueur
et ensuite tu as un flag de 2 octets qui te fournis différentes information
pour savoir si il est encrypté , compressé ...
tu te doute bien qu'un copier collé de deux fichier l'un derrière l'autre ne peut pas fonctionner
01/07/2016, 17h43
Sve@r

Citation:

Envoyé par Cfass

J'avais pensé à cette solution en premier. Sauf qu'en faisant cela le fichier chiffré était completement illisible.

Bien entendu. Il faut le déchiffrer pour qu'un lecteur audio puisse le lire. Ou alors tu inventes aussi le lecteur qui déchiffre et qui lit...

Citation:

Envoyé par Cfass

Alors, ayant vu cela, j'ai donc tout simplement voulu transposer le contenu d'un même fichier mp3 dans un autre (faire une copie) juste pour tester mais déja la taille du fichier obtenu n'avoisinait même pas celle du fichier original et du coup c'était illisible sur un lecteur audio.

Tu t'es forcément vautré dans ton code. Je connais pas Java mais en C et dans d'autres langages (surtout sur des plateformes Windows) il est nécessaire de spécifier explicitement que tu travailles en binaire sinon les fonctions de lecture et surtout d'écriture s'imaginent que c'est du texte sensé être lisible par notepad et rajoutent alors des octets permettant à notepad (et autres éditeurs Windows) de repérer les fins de lignes. C'est un problème qu'on se traine depuis 50 ans parce qu'un jour deux types n'ont pas pu se mettre d'accord et que l'un des deux a voulu représenter les fichiers textes comme les lettres écrites à la machine à écrire, avec le bras qui faisait revenir le charriot au début de la ligne tout en faisant avancer le papier. Il a donc défini un caractère "retour charriot" et un autre "line feed" et dans son esprit, toute ligne se doit de posséder ces deux caractères accolés. Alors que l'autre type, plus pragmatique, a pensé "pourquoi mettre 2 trucs là où un seul suffit". D'où depuis les bascules ascii/binary lors des transferts ftp, les fichiers textes Unix copiés sur clefs USB et ne pouvant pas s'ouvrir avec notepad (ou alors avoir tout le fichier sur une seule ligne) et ce fameux mode "r/w" du C agrémenté d'un "b" supplémentaire si le fichier doit être traité en binaire...