Bei kleineren Coop-Projekten wäre es sehr nett, wenn mehrere Sequencer das direkt Abspielen dieser Formate beherrschten.
Ja, das wäre in der Tat sehr nett. Wenn alle am Projekt Beteiligten einen Sequencer hätten, der .omf lesen und exportieren kann ist letzteres in Verbindung mit z.B. einem .rar Packer oder Ähnlichem aber noch schöner. Weil erst einmal nur das gespeichert werden muss, was zu einem Zeitpunkt x überhaupt spielt und man das alles importieren kann incl. Tempo, Taktinformationen, mit Midi und alles an seinem Platz ist, wo es hin gehört ohne zu verrutschen.
Kleiner Tip zu FLAC/ APE : wenn man kein Reaper, kein Studio One oder kein aktuelles Cubase u.s.w hat : ich verwende auf dem MAC hierzu das Programm "Max", das wirklich fast jedes x-beliebige Packformat egal ob Verlustbehaftet oder Verlustfrei, in jedes x- beliebige Zielformat, per "Batch" konvertieren kann. Darunter sind auch FLAC, OGG, APE u.v.m.
http://sbooth.org/Max/ D.h. auch wenn es ein ganzes Projekt ist, die Konvertierung dauert incl. Einstellungen des Zielformates nur wenige Minuten und geht zuverlässig.
So, um jetzt mal mit den Vorurteilen aufzuräumen, es lässt sich mit FLAC oder APE exakt das identische Quellmaterial wieder herstellen, es geht gar nichts verloren und klingt auch nicht schlechter oder anders, das ist wirklich Humbug.
Man macht also nichts anderes als sich den typischen Verlauf der Wellenformen in einem Audio File so auszunutzen, damit man verlustfrei codieren und decodieren kann und dabei Festplattenplatz spart. Würde man völlig chaotisches Rauschen in den FLAC oder APE Algorithmus schicken das sich bei Stereo Files auch noch links und rechts unterschiedlich wäre, würde die Datei eher größer statt kleiner werden.
Klingen tut´s nicht anders, wenn der Programmierer beim Codieren oder Decodieren keinen Fehler gemacht hat, ist das Verfahren absolut verlustfrei. Das Codieren verlangt etwas mehr CPU, weil es die Daten analysieren muss, um die best mögliche Packdichte fest zu stellen, es stellt fest wo es angebracht ist einen Befehl abzusetzen wie "so ... jetzt kommt 30.000 Mal die Null", bestimmte Folgen von Werten zu erkennen oder mitzuteilen, so, jetzt kommt 25.000 Mal der original Datenstrom, weil das Material ist so komplex, dass ich es nicht weiter packen kann ...". Das Decodieren ist für die heutigen Prozessoren keine Kunst und u.U. sogar schneller und effizienter, als den kompletten Datenstrom von einem Datenträger lesen zu müssen auch wenn die immer schneller werden.
Was Kickback schon angeschnitten hat, .RAR macht nicht viel anderes, es erkennt, dass ein ähnlicher Packalgorithmus wie FLAC oder APE (beide letzteren haben aber je nach Geräuschhaftigkeit der Wellenform wiederum Vorteile was die Packdichte und die Effizienz des Decodiervorgangs angeht sowieso) auf die Beschaffenheit von .wav Dateien besser passt und wendet genau dieses Verfahren statt einem Verfahren an, was dem Algorithmus von z.B. .zip sehr ähnelt und häufig hinter den Packwerten von .RAR, FLAC oder APE zurück stecken muss. Also wie man es unschwer aus der Praxis erkennen kann, .zip oder .rar stellen ja auch 1:1 die Dateien wieder so her, wie sie einmal waren. Klar, in .WAV oder auch .AIF Dateien kann man Zusatzinformationen wie Tempo, Copyritghts, etc. speichern, die gehen natürlich durch .FLAC oder .APE verloren, sie werten nur den reinen Audio- Datenstrom aus und ignorieren diese Zusatzinformationen.
Noch Fragen ? Die Algorithmen von FLAC und APE sind auf deren Webseiten offen gelegt und lassen sich auch von nicht so fortgeschrittenen Programmierern durchaus halbwegs verstehen.
Sehr interessant ist auch folgende Seite :
http://www.bobulous.org.uk/misc/lossless_audio_2006.html