Beiträge von lidocorc

Es ist natürlich prinzipiell möglich, Tonspuren, die von importierten ogg-Dateien stammen, zu schneiden und das Ergebnis wieder im ogg-Format zu exportieren. Führt die Hin- und Herübersetzung von ogg ins interne Datenformat und zurück nach ogg zu Qualitätsverlusten? Kann man vielleicht eine eventuelle Qualitätseinbuße vermeiden, indem man beim Export eine höhere Qualitätsstufe einstellt? Gibt es eine Regel, die besagt: Wenn man ogg-Daten, die auf sounsoviel kbits/s komprimiert sind, einliest und nach dem Schneiden wieder exportiert, dann sollte man mindestens Stufe soundso für den Export einstellen?

Oder sollte man sich besser nach einem Programm umsehen, dass auf das Schneiden von Tonspuren im ogg-Format spezialisiert ist?

Gruß von lidocorc

Ich möchte für einen messtechnischen Zweck (also nicht für eine Musikaufnahme) die Soundkarte auf eine geringere Abtastrate als den Standardwert 44100 Hz einstellen. Laut "Audio Device Info" (unter "Hilfe" im Menü zu finden) verfügt die Peripherie des ADC über Raten 8000 Hz, 9600 Hz, 11025 Hz, etc..

Bedeutet die Eingabe einer bestimmten Projektfrequenz (in der gleichnamigen Werkzeugleiste), dass Audacity der Soundkarte diese Abtastrate mitteilt und diese ihre Abtastrate danach umstellt oder bedeutet es nur, dass Audacity "resamples", also geeignet zwischen den häufigeren Abtastungen der Soundkarte interpoliert? Wenn letzteres der Fall wäre, gäbe es eine Möglichkeit die Soundkarte anderweitig auf eine bestimmte Abtastrate einzustellen, vielleicht sogar mit Windows-Bordmitteln?

Vielen Dank für Hinweise.

Gruß von lidocorc

Ich dachte erst, V1.3.9 würde das o.g. Problem anpacken, tut es aber nicht.

(So nebenbei würde mich interessieren, was neu an 1.3.9 ist. Sicher gibt es ein change log für die Versionsänderung. Wo finde ich die, bitte?)

lidocorc

Ja, Markus, das hat geholfen. Du hattest einen guten Riecher. Danke.

Der Einfachheit halber habe ich in "Systemsteuerung/Regions- und Sprachoptionen/Regionale Einstellungen/Standards und Formate" in der Drop down Liste "Englich (USA) gewählt, womit die Umstellung auf "." als Dezimaltrenner gegeben ist.

Aber jetzt würde ich doch Audacity gerne verwenden, ohne meinen Rechner jedes Mal vorher neu zu lokalisieren. Ist es sinnvoll, im Nyquist-Quellcode an bestimmten Stellen patches vorzunehmen, damit ich mir das Umstellen hin und her erspare?

Andererseits dürften alle Benutzer im deutschen Sprachraum davon profitieren, wenn die Installations-Exe-Datei gleich passend lokalisiert wäre. Kurz gesagt, soll ich lieber ein wenig warten?

Gruß von lidocorc

Ich habe die Version 1.3.7. deinstalliert und anschließend Version 1.3.8 installiert. Jetzt gehen verschiedene Plug-ins (und zwar diejenigen, die bereits in der Installationsdatei "audacity-win-unicode-1.3.8.exe" enthalten sind) nicht mehr, z.B. das Hochpassfilter, Tiefpassfilter. Es kommen Meldungen wie "Nyquist gab diesen Wert zurück: <Zahl>". An der Wellenform einer Spur wird nichts verändert. Andere Filter dagegen funktionieren, z.B. Hardlimiter, GVerb. Mein Betriebssystem: Windows XP Prof.

Sicherheitshalber habe ich noch einmal deinstalliert und installiert. Ergebnis dasselbe.

Für einen Tipp, was zu tun ist, wäre ich dankbar.

lidocorc

Das steht so in
http://www.audacity-forum.de/d…ity-1.3-help/envelope.htm

Schade, dass Audacity stets die ganze Tonspur mit der ganzen Hüllkurve multipliziert. Die Abschnittslösung wäre eleganter.

Wenn man eine Hüllkurve einer Tonspur einprägen möchte, dann muss man "Mix and Render" auf die Tonspur anwenden. In der Bedienungsanleitung ("Hilfe") lese ich, dass man den Abschnitt der Tonspur, in dem die Hüllkurve eine Änderung bewirkt, vor dem "Mix and Render" markieren sollte. Das erscheint mir sinnvoll, denn dann weiß Audacity, wo Veränderungen zu beachten sind und braucht nur diesen Tonspurabschnitt neu berechnen. Den Rest der Tonspur kann Audacity so lassen wie er ist; an ihm soll sich ja nichts ändern.

Ich beobachte, dass die Verarbeitung durch "Mix and Render" unverhältnismäßig lange dauert. Um einen 10 s dauernden Abschnitt einer Tonspur, auf dem die Hüllkurve wirkt, zu berechnen, braucht mein PC insgesamt ca. 30 s. Ich vermute, dass das Markieren des relevanten Abschnitts unwirksam war, denn ohne ein Markieren ("blaufärben") dauert "Mix and Render" genauso lang. Offenbar rechnet Audacity doch die ganze Tonspur durch, ganz gleich, ob ein Abschnitt markiert ist oder nicht.

Habe ich Audacity falsch bedient? Ich hoffe, dass ich nicht einem Bug auf der Spur bin.
Gruß von Lidocorc

Ich verwende Version 1.3.5 auf Windows XP SP2.

Markus

Den Auslöser des Fehlers habe ich endlich gefunden. Nachdem ich auf Teufel-Komm-Raus alles Mögliche getestet hatte, fand ich durch Zufall, worauf es ankommt: Es ist die Solo-Taste im Kopf einer Spur.

Erzeuge oder importiere eine Stereo-Spur x-beliebigen Inhalts (eine einzige Spur genügt). Wenn du die Solo-Taste drückst (was bei einer einzigen Spur keinen Sinn hat, hier dient es dem Vorführzweck), dann ist der Export beschädigt und nur der linke Kanal erscheint in der Exportdatei. Nachdem die Solo-Taste wieder zurückgenommen ist, gelingt der folgende Export fehlerfrei. Die Sache ist beliebig wiederholbar: Solo gedrückt, Fehler da; Solo losgelassen, Fehler weg.

Ich hoffe, du hast jetzt den entscheidenden Hinweis, den Fehler auch im Code zu finden.

Gruß Heinrich

Jetzt hab ich's verstanden!

Nachdem die Spur exportiert ist, kann ich sie fehlerfrei abspielen. D.h. die Spur präsentiert sich dem Benutzer vor und nach dem Export sowohl optisch als auch akustisch als fehlerfrei.

Beobachtung 3 (jetzt wird's lustig!): Es ist nicht nötig, die "beschädigte" Spur zu speichern und neu zu laden, um sie fehlerfrei zu bekommen. Wenn man eine andere Stereospur, die gleichzeitig von Audacity verwaltet wird, exportiert und dies fehlerfrei gelingt, dann lässt sich die "beschädigte" Spur anschließend ebenfalls fehlerfrei exportieren.

Für mich (der den Aufbau von Audacity nicht kennt) sieht es jetzt so aus, als ob der Fehler nicht darin bestünde, dass an der Repräsentation der Spur ein Schaden eintritt, (man sollte also nicht von einer "beschädigten" Spur reden) sondern dass eher eine Übergabemethode der Spurobjekte, die den Inhalt einer Spur an die verschiedenen Exportprozeduren verteilt, in einen Fehlerzustand gerät, der erst mit der Übergabe einer neuen Spur wieder aufgehoben wird oder werden kann.

Hoffe, du kommst etwas vorwärts mit dieser Beobachtung.

Anschließend werde ich prüfen, ob es die Monospur-Abschnitte sind, die ich in die Stereospur hineinkopiert habe, welche zum Fehler führen. Gerade eben ist der Fehler unter einem anderen Umstand aufgetreten. Ich habe erst die Monospur dupliziert, dann die Monospur mit ihrem Duplikat zu einer Stereospur vereinigt. Aus dieser Stereospur kopiere ich Abschnitte in die später zu exportierende Stereospur. Von "Mono" sieht die zu exportierende Spur dann gar nichts mehr. Dennoch tritt der Fehler auf.

Verstehe deine Frage nicht ganz, Markus. Wahrscheinlich war ich in meiner Beschreibung zu ungenau.

Im Audacity-Hauptfenster habe ich mehrere Spuren, davon interessiert nur eine einzige. Diese ist eine Stereospur. Sie und nur sie soll exportiert werden. Dazu wird sie fokussiert. (Ein gelber Rahmen ist jetzt außen herum und die Spurfläche wird dunkelblau - jedenfalls beim üblichen Windowsfarbschema.) Der Menübefehl "Auswahl exportieren ..." wird gegeben.

Das Ergebnis des Exports heiße blabla.wav. Diese Datei blabla.wav importiere ich in ein neues Audacity-Fenster. Es zeigt sich, wie gewünscht, eine Stereospur. Aber nicht dieselbe, die Vorlage des Exports war: Sie ist nur hinsichtlich des linken Kanals identisch mit der Vorlage, der rechte Kanal ist Stille (konstant Null).

Zurück zu deiner Frage. Spielt man blabla.wav in einem (beliebigen) Player ab, dann hört man nur im linken Lautsprecher, was man hören soll. Im rechten kommt nix (außer Verstärkerrauschen ).

Entschuldige, das war jetzt sehr umständlich formuliert. Ich wollte aber sicher gehen, dass keine Unklarheit bleibt.

Weit bin ich nicht gekommen mit zusätzlichen Details.

Beobachtung 1: Wenn ein Export einer (wie vormals beschrieben) bearbeiteten Stereospur mit dem geschilderten Fehler behaftet ist, dann sind alle Wiederholungen des Exports dieser Spur ebenso fehlerbehaftet. Das heißt, die Zufälligkeit des Auftretens des Fehlers liegt nicht im Exportvorgang. Es scheint, als wäre die Stereospur intern irgendwie beschädigt (auch wenn man es der Tonspur im Fenster nicht ansieht) und folglich tritt bei jedem Export derselbe Fehler auf. Das Eintreten der Beschädigung jedoch scheint ein zufälliger Vorgang zu sein. (Da der PC aber eine deterministische Maschine ist, sind in Wirklichkeit verborgene Parameter am Werke.)

Beobachtung 2: Speichert man die Stereospur innerhalb eines aup-Projekts auf Festplatte, löscht es in Audacity und lädt dieses Projekt anschließend wieder (Audacity muss also nicht beendet werden), dann ist die Stereotonspur fehlerfrei. Nachfolgende Exporte gelingen sämtlich.

Zu tun bleibt: Wie kann man auf möglichst einfache Weise eine Tonspur herstellen, die in der beschriebenen Art beschädigt ist? Ich könnte natürlich meine Wav-Dateien übermitteln und jeden Handgriff der Bearbeitung beschreiben, aber eine Reduktion auf das Wesentliche wäre wünschenswert. Das braucht aber noch eine Weile.

Höchstwahrscheinlich auf meinen Thread: Verfasser lidocorc, Datum 28.4.08, zu finden in dieser Rubrik. Titel: Fehler bei Export auf .wav-Datei

Nun, "dein" Bug ist "meinem" wirklich ähnlich. Mir ist klar, dass die Programmierer nur eingreifen können, wenn sie den Fehler auf ihren Maschinen reproduzieren können. Ich bin erst gestern abend auf den Fehler gestoßen und hatte noch keine Gelegenheit intensiver die Voraussetzungen für sein Auftreten einzugrenzen. Wenn aber der mp3-Export ähnlich fehlerbehaftet ist wie der wav-Export, dann liegt es nicht an der "Übersetzung" in ein bestimmtes Ausgabeformat, sondern an der audacity-internen Repräsentation der zu exportierenden Tonspur.

Sobald ich mehr weiß, werde ich es im Forum mitteilen.

Gruß lidocorc

Ich beziehe mich auf Version 1.3.4 beta. Betriebssystem Windows XP professional SP2.
Beim Export einer Stereo-Spur mit dem Menü-Befehl "Datei > Auswahl exportieren ..." tritt ein Fehler auf, wenn die markierte Spur als Windows-Wave-Datei mit 16bit PCM Qualität ausgegeben wird. Die erzeugte Wav-Datei enthält nur den linken Kanal, der rechte Kanal ist Stille.

Dieser Fehler trat unregelmäßig auf. Bei 20-facher Wiederholung des Exports trat er 6 mal auf, 14 mal nicht. Vielleicht ist von Bedeutung, dass die Stereo-Spur, die die Vorlage für den Export bildete, eine importierte wav-Datei in Stereo war. Ich fügte dann in diese einen Abschnitt aus anderen Spur, die allerdings Mono war, ein. Audacity fügte, wie erwartet, den Mono-Abschnitt so ein, dass er auf beiden Kanälen der Stereospur erschien. Im Anzeigefenster sah alles ganz wie gewünscht aus. Wendete ich dann wie oben gesagt "Datei > Auswahl exportieren ..." an, dann war es Glückssache, ob das Ergebnis des Exports beide Kanäle enthielt.

Ich weiß mir keinen anderen Rat als solange den Export zu wiederholen, bis die Kontrolle des Ergebnisses befriedigt.

Erratische Ereignisse sind immer fehlerverdächtig. Vielleicht habe ich aber doch irgendeinen Handgriff getan, ein andermal wieder nicht, der dann die Ursache für das unterschiedliche Verhalten war. Ganz sicher ausschließen kann ich Bedienungsunterschiede nicht.

Vielleicht hat jemand ähnliche Beobachtungen gemacht und kann helfen?

Bin gerade im englischsprachigen Forum auf eine Fehlermeldung gleichen Inhalts wie meine gestoßen. Autor: marbo, Datum: 27.12.07. Er macht dieselbe Beobachtung wie ich und kommt auch zum selben Schluss beim Einkreisen der Fehlerursache.

Kleine Bugs mit Textmarken in V1.3.4

1. Man kann Anfang und Ende einer Textmarkierung im Editfenster in verschiedenen Formaten festlegen, z.B. in hh.mm.ss + samples oder ganz allein in samples. Macht man einen Eintrag in diesem Format, so wird die Zahl der Samples i.a. nicht so akzeptiert, wie man sie eintippt. Audacity rundet intern auf den nächsten ihm passenden Wert. Ich habe nicht weiter gebohrt, welche Werte das sind und ob das interne Rundungsraster etwa von der Samplefrequenz des Projekts abhängt. Die Entwickler haben das sicher viel schneller heraus. Jedenfalls ist die Bedienung in diesem Punkt noch nicht ausgereift.

2. Die Unter- und die Obergrenze zweier Textmarkierungen haben in V1.3.4 die Eigenschaft aneinanderzuhaften, wenn sie zeitlich zusammenfallen. Das ist sehr nützlich. Irgendwie ist es ein Unterschied, ob man die Grenzen, die aneinanderhaften sollen, mit der Maus innerhalb der Tonspur zusammenführt oder ob man ihre Zeitpunkte über den Textmarkierungseditor auf identische Zeitpunkte einstellt. Es passierte mir immer wieder, dass Textmarkierungsgrenzen nicht mehr aneinandergeklebt haben, nachdem ich einige Schnitte in den Tonspur(en) - und zugleich der Textspur - vorgenommen hatte. Hier müsste ich wohl noch genauer nachsehen, um den Bug genauer eingrenzen zu können.

3. Man kann die Textmarkierungen als Textdatei exportieren. Dabei werden die Zeitpunkte für Anfang und Ende der Textmarkierung auf Mikrosekunden genau angegeben (also feiner als es Samples entspräche, jedenfalls für fs <= 1MHz)). Merkwürdig ist, dass 'zusammenklebende' Grenzen (also wenn Ende einer vorausgehenden Markierung und Anfang der nächsten übereinstimmen), die sowohl in der Textspur zusammenklebend dargestellt werden als auch im Textmarkierungseditor dieselben Zeitpunkte aufweisen, in der exportierten Datei nicht zusammenfallen. Da muss irgendwas nicht stimmen.

4. Im Textmarkierungseditor lassen sich ähnlich wie in der Schreiboberfläche einer Tabellenkalkulation Zeilen und Spalten fokussieren (d.h. bei Windows-Standard-Farbgebung blau einfärben). Ich wollte eine Zeile einfügen, habe, so wie man es in Tabellen gewohnt ist, auf den Zeilenkopf geklickt und geglaubt, dass der Button 'Davor Einfügen' oberhalb der blauen Zeile eine Leerzeile erzeugen würde. Es wurde eine Leerzeile eingefügt, aber nicht oberhalb der blauen Zeile sondern oberhalb der fokussierten Zelle (dick umrandet). Wozu ist eigentlich die farbliche Hervorhebung von Zeilen und Spalten (das geht nämlich auch) gedacht?

So jetzt reicht's einmal für eine Weile mit hilfreichen Beiträgen. Es wird Weihnachten. Ein Fest, das keinen Computer braucht.

Zitat von Markus

Zitat

Es gibt bereits den Befehl Bearbeiten/Clips verbinden (Strg+J).

Ctrl+J ist als Menübefehl bekannt. Der Befehl 'Clips verbinden Ctrl+J unterscheidet sich von 'Merge' darin, dass jener den späteren Clip zeitlich nicht verschiebt und in die Lücke Stille einfügt. Merge dagegen rutscht den nachfolgenden Clip 'nach vorne', so dass sich die Lücke schließt.
Insofern handelt es sich um zwei verschiedene Werkzeuge, die m.E. nicht nur verschiedene Namen, sondern auch verschiedene Hot Keys und Menüeinträge verdienen.

Ich persönlich finde es angenehm, wenn ein Bedienkonzept Ausnahmen vermeidet. Ich möchte Audacitys Bedienkonzept durchaus als übersichtlich bezeichnen, auch wenn Goldwave-Benutzer anderer Meinung sein sollten. Doch sollte man die Tradition pflegen und nicht mit neuen Features die klare Linie verlassen.

Dieser Beitrag soll nicht als Nörgeln verstanden werden. Er ist gedacht als Feedback an Entwickler, die sich aus der Summe der Anwendermeinungen ein Bild von der Resonanz ihrer Bemühungen machen wollen.

Eine Anregung für künftige Versionen.

Die Fensterbreite (in Samples gezählt) lässt sich sowohl im 'Equalizer' als auch in der 'Frequenzanalyse' einstellen (in der Frequenzanalyse stufenweise bis 2**14, im Equalizer bis 2**13, in den Spektrogrammen nur bis 2**12). Diese Einstellung wirkt sich unmittelbar auf die Frequenzauflösung der Verfahren aus. Eine hohe Frequenzauflösung aufgrund breiter Fenster ist in der Regel wünschenswert, erfordert aber einen höheren Rechenaufwand. Da die Rechenleistung der CPUs und FPUs mittlerweile so hoch ist, dass Fensterbreiten von 2**14 keine erhebliche Verzögerung mehr bedeuten, würde es die Leistungsfähigkeit des Programms deutlich steigern, wenn man z.B. Fensterbreiten bis 2**16 oder noch mehr zulassen würde. Dem Anwender bleibt die Wahl des Parameters ja unbenommen. Für die Programmierer dürfte das Einrichten erweiterter Einstellmöglichkeiten auch nur ein Klacks sein.

Ein weiteres Argument: Die Frequenzauflösung hängt zunächst zusammen mit der zeitlichen Breite des Fensters, nicht mit der Anzahl der Abtastungen. Wenn man die Sampling-Rate von 44100 Hz auf 96000 Hz oder gar auf 192000 Hz steigert, die Anzahl der Abtastungen aber (z.B. 8192) gleich lassen muss, da sich kein höherer Wert mehr einstellen lässt, dann sinkt die Frequenzauflösung auf die Hälfte oder gar ein Viertel. Dies führt bei tiefen Frequenzen zu einer recht schlechten Frequenzauflösung, die den Equalizer z.B. zum Unterdrücken von Netzbrumm unbrauchbar macht. (Ich weiß, man sollte den Netzbrumm erst gar nicht in das Soundfile hineinbringen, man kann das Kerbfilter nehmen, man kann ...)

Wenn zwei Clips bis auf einen hinreichend geringen Abstand zusammengeschoben sind (mit dem Verschiebewerkzeug), dann wird das Ende des vorausgehenden Clips dicker dargestellt (sog. Schnittlinie). Klickt man drauf, dann verschmelzen die zwei Clips zu einem. Das ist sehr praktisch. Ich hielte es für günstig, wenn es auch einen Menübefehl 'Merge' (oder 'Verschmelzen') dazu gäbe. Nicht etwa, weil ich ihn gegenüber einem Klick bevorzugen würde, sondern weil das Menü einen guten Überblick darüber erlaubt, was es an Bearbeitungsmöglichkeiten alles gibt.

Ich finde für Ctrl+Shift+M ('Mix and Render to New Track') keinen Menüeintrag. Der wäre sinnvoll, denn das überschreibende 'Spuren zusammenführen' hat einen.

Gibt es eine Übersicht über alle Hot Keys von Audacity? Ctrl+M scheint etwas zu bewirken, ich kriege aber nicht heraus, was es ist.

Auf einem weiteren Rechner mit anderer Hardware bekomme ich unter gleichen Umständen denselben Absturz. Allerdings gibt sich Audacity hier etwas weniger zugeknöpft und bietet eine aussagekräftigere Fehlermeldung an (sonst würde ich nicht noch einmal posten):

Die Ausnahme "unknown software exception (0x40000015) ist in der Anwendung an der Stelle 0x004b196f aufgetreten. Klicken Sie...."

Problemsignatur .... Offset 00011a0e

In dem Meldungsfenster kann man dann durch Anklicken weitere Details erfahren, u.a. bekommt man einen Hex Dump. Sollte der zu etwas taugen, kann ich ihn nachliefern. Ist aber eine üble händische Abschreibarbeit, denn es ist kein Export in eine Textdatei möglich.

Audacity 1.3.4 zeigt unter Windows XP Professional SP2 einen kritischen Bug.

Reproduktion des Bugs:

0. Der Rechner ist neu gestartet. Es liegen also keine Überbleibsel vorhergehender Audacity-Instanzen im Speicher.

1. Ein Projekt wird geladen, bestehend aus einer Tonspur in Mono (44100 Hz, 32-Bit), Länge unkritisch, z.B. 30 s. Man kann beispielsweise eine Tonspur mit 30 s Sinuston füllen.

2. Die Zeitskala der Tonspur wird mit 'Einzoomen' bzw. 'Auszoomen' so gewählt, dass eine Bildschirmbreite 13s, 6,5s oder weniger entspricht. Bei 26s, 52s und mehr tritt der Bug nicht auf. In den Einstellungen wird im Tab 'Programmoberfläche' die Option 'Update Display while playing := true' gesetzt. Falls die Option nicht gesetzt ist, tritt der Fehler ebenfalls nicht auf.

2. Mit Taste R wird eine neue Tonspur erzeugt und eine Aufnahme begonnen. (Es ist unerheblich, wo der Cursor der bereits vorhanden Spur steht, d.h. in welcher zeitlichen Relation die neue Tonspur zur alten steht.)

3. Nachdem der rote Tonspurcursor das 'Zeilenende' der Tonspur erreicht hat und die Tonspur auf die 'nächste Seite umgeblättert' hat, stürzt das Programm ab. Dabei erscheint für sehr kurze Zeit eine Fehlermeldung: "An unhandled exception occurred. Press 'Abort' to terminate the program ..." Drücken braucht man nicht. Audacity geht von selbst.

Wenn man im deutschen Forum zum Suchbegriff 'Absturz' recherchiert, findet man sehr viel, darunter die wunderlichsten Absturzumstände. Jedoch passt keiner auf meinen Befund. Zur Überprüfung des Sachverhalts werde ich, wenn ich wieder Zugang zu einem weiteren Rechner habe, auf dem Audacity 1.3.4 unter Windows - aber mit gänzlich anderer Hardware - läuft, prüfen, ob 'mein' Bug sich dort auch zeigt. Da der Bug offenbar mit der Tonspurdarstellung und dabei wahrscheinlich mit dem Timing zu tun hat, interessiert mich, wie sich Audacity hinsichtlich dieses Bugs auf einem älteren und deutlich langsameren Rechner verhält.