ENGLISH VERSION |
|
Links | | | Forum | | | Kommentare | | | News melden |
Chat | | | Umfragen | | | Newsticker | | | Archiv |
amiga-news.de Forum > Suche | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
||||||
platon42
[Ex-Mitglied]
30.10.2007, 08:52 Uhr [ - Direktlink - ] |
Thema: TLSFMem und PAB
Brett: Amiga, AmigaOS 4 Zitat: Was ich sicher nicht nötig habe, ist mich mit dieser "Community" (oder was da so an Leuten übrig geblieben ist) abzugeben. Das war sicher mein letztes Produkt für den Amiga. Du willst ein Nein hören? Nein, ich lasse mich nicht erpressen oder auf diese Art und Weise zensieren. -- Best Regards Chris Hodges [ Dieser Beitrag wurde von platon42 am 30.10.2007 um 08:54 Uhr geändert. ] |
|||||
platon42
[Ex-Mitglied]
29.10.2007, 19:36 Uhr [ - Direktlink - ] |
Thema: TLSFMem und PAB
Brett: Amiga, AmigaOS 4 Nachdem ja gerade der Kommentarbereich zum Thema geschlossen wurde, ohne dass ich eine Stellungnahme dazu abgeben konnte: Mir ist nicht klar, was diese Diskussion hier soll. Welche persönliche Meinung ich zu PAB habe, sollte auch schon vor dem Readme bekannt gewesen sein und steht nicht zur Disposition. Im Readme steht ja auch nicht, *** Wegen Verstoß gegen die Netiquette gelöscht (cg) http://www.amiga-news.de/netiquette.shtml *** Das ist freie Meinungsäußerung. Ich muss nicht mit jedem *e** auf dieser Welt auskommen. Platon (der alte, tote Grieche, nicht ich) hat mal gesagt: "Ich kenne keinen sichern Weg zum Erfolg, nur einen zum sicheren Misserfolg - es jedem recht machen zu wollen.". Und dazu gehört auch jene Fraktion der merkbefreiten* Spindoctors**, zu denen ich auch PAB zähle. Jede vernünftige Diskussion wird im Keim erstickt, weil PAB entweder nicht die Argumente und Fakten nicht liest, sie ignoriert oder verdreht. Das ist Kindergarten. Darauf habe ich echt keine Lust, dafür ist das Leben echt zu kurz. * http://de.wikipedia.org/wiki/Merkbefreiung ** http://de.wikipedia.org/wiki/Spin_Doctor Aber zum Thema, noch einmal zusammengefasst (aus meiner Sicht!): - PAB fragt "Basiert dieser Allokator eigentlich darauf, die OS-Routinen zu patchen ?" und "Wenn ja: wie hoch ist der Overhead und lohnt sich dann auf langsamen Systemen (wie den Classic-Rechnern) der Einsatz im Alltagsbetrieb ?". Letztere Frage ist eh schon abstrus, weil wenn ein System langsam ist, dann sollte man doch gerade da angreifen, wo viel CPU vergeudet wird. - PAB provoziert mit 5000*O(1) vs. O(1), was völlig ohne jegliche Basis ist. - ich schreibe: Es ersetzt die OS-Routinen vollständig. - ich schreibe: Dass der Patch ansich insgesamt ca. 2400 Bytes groß ist, für alle Routinen und keine Schleifen enthält, dass dadurch der Overhead nicht hoch sein kann. Aber darum geht es ihm nicht. Er will die Software schlechtreden. - PAB schreibt: "Ein verschachtelter Funktionsaufruf (=patch) kann langsamer sein, als ein paar Pointer mehr durchzuiterieren." Das ist Bullshit, denn ein Patch ist kein verschachtelter Funktionsaufruf. Und es geht nicht um ein "paar Pointer mehr", wie PAB auch weiß! Er weiß sicher, dass das Speichersystem schnell stark fragmentiert und dass es ganz plötzlich hunderte oder tausende Pointer sind, die man durchiterieren muss. Immer noch nicht klar, worauf er hinaus will? Er schreibt weiter: "Die Alltagsgeschwindigkeit scheint aber auf jedenfall nicht drastisch unterschiedlich zu sein." Wahrscheinlich hat ers selbst nicht einmal getestet -- aber darum geht es nicht: Einfach mal so tun als ob. Egal ob fundiert oder nicht. - PAB schreibt weiter: "Einfach zu schreiben "o(1)" ist besser als alles andere, halte ich für falsch, obwohl es für einen Informatiker korrekt scheint, in der Realität aber durchaus (je nach Implementation - sprich: Overhead, deshalb frage ich danach!) länger dauern kann, als o(n^3). Es kommt halt auf das n an und die Konstanten, mit denen man multiplizieren muß, wenn man die *reale* Rechenzeit bestimmen oder vergleichen will." Ich schrieb bereits, dass der Overhead minimal ist, aber das ist PAB egal. Wieder kommen diese fadenscheinigen "aber die Konstante!!" Aussagen. Und worauf sich dein "Erklärungsversuch" von O(i) beziehen sollte (schreib doch bitte groß-O, wenn Du groß-O meinst, da klein-o ja eine andere Bedeutung hat) war mir schon klar. Trotzdem bleibt es falsch. Aber das kannst Du ja nicht einfach zugeben. Es handelt sich beim Einsatz in der O-Notation eben *nicht* um einen Index oder einen Iterator -- das ist schlicht falsch. - ich versuche es nochmal: "Es gibt einen Grund, warum man die O-Notation für Speicher- und Laufzeitkomplexität eingeführt hat -- eben, um die objektive "Güte" eines Algorithmus zu bestimmen bzgl. der Eingabegrößen. Es geht hier auch nicht um einen Algorithmus, der O(n^1.67) hat im Vergleich zu O(n^1.53), sondern um O(1) vs. O(n) mit n >> 0." - PAB: "Die Frage nach dem Overhead bei gepatchten Funktionsaufrufen drängt sich nunmal nicht nur mir auf, wie hier unschwer zu erkennen ist. Und daß *in*der*Realität* o(xxx) nicht gleich yyy*o(xxx) ist, das stimmt doch, oder etwa nicht !?!? Die ganze o-Geschichte ist zwar nett, aber nur aussagekräftig für sehr große n, sonst ist sie schlicht irrelevant - und ob die ns hier sehr groß werden, kann *ich* nunmal *nicht* einschätzen - da wird man doch noch fragen dürfen !?!?" Mit dieser Aussage wäre er bei jedem Informatik-Prof sofort durchgefallen. Es geht hier nicht um "sehr große n", ab denen das gilt. Schonmal gesehen, wie O(n^n) wächst? Und außerdem hatten wir bereits geklärt, dass n eben schon ziemlich groß ist beim AmigaOS *und eben ständig wächst* während des Betriebs, während O(1), oh Überraschung immer O(1) ist. Armin schreibt dazu gottseidank: "Solch dämliche PAB Fragen müssen von Leuten mit Ahnung als Trolling aufgefasst werden. Natürlich benötigt eine raffiniertere, aufwändigere Speicherverwaltung ein paar Takzyklen mehr als die extrem simplen Funktionen, wie sie im original AmigaOS verwendet werden. Da aber weniger Speicherfragmentierung verursacht wird und das Suchen in den Speicherlisten schneller geht, wird die neue Methode nach etwas "längerer" Uptime mit Sicherheit auch wesentlich effizienter sein." Noch ein Beispiel? - PAB schreibt bzgl. O(i) "Setze jede beliebige Zahl für "i" ein, denn i steht in der Regel für "iterator" oder "index"". - ich antworte: "i steht nicht für iterator oder index. Der Ausdruck x in O(x) steht für eine Eingabegröße in einem Algorithmus, die sich normalerweise ändert und daher für die Laufzeit relevant ist. Es können auch mehrere Größen sein,..." - PAB antwortet: "Übrigens: "i = index" war eine Antwort auf die Frage, wofür o(i) steht. Die Aussage selbst ist richtig, egal, was Du für i einsetzt - es dürfen auch Hosenträger sein..." Was wieder falsch ist, klar dürfen es Hosenträger sein, aber *index* dem Begriff nach ist eine Laufvariable und das ist eben völliger Bullshit. Aber vielleicht ist das auch der Grund, dass PAB nach über 10 Jahren des "Studierens" verschiedenster Fächer immer noch keinen Abschluss hat? - Ich antworte (letzter Versuch): Und worauf sich dein "Erklärungsversuch" von O(i) beziehen sollte (schreib doch bitte groß-O, wenn Du groß-O meinst, da klein-o ja eine andere Bedeutung hat) war mir schon klar. Trotzdem bleibt es falsch. Aber das kannst Du ja nicht einfach zugeben. Es handelt sich beim Einsatz in der O-Notation eben *nicht* um einen Index oder einen Iterator -- das ist schlicht falsch. - Und PAB ignoriert es abermals und besteht auf seiner Richtigkeit. Und das war nicht die erste Diskussion, die so völlig sinnlos verlief. Das bringts nicht. Meines Erachtens fehlt es PAB an etwas, dass man auch als gesunden Menschenverstand oder Einsicht bezeichnen könnte. -- -- Best Regards Chris Hodges [ Dieser Beitrag wurde von cgutjahr am 31.10.2007 um 05:04 Uhr geändert. ] |
|||||
platon42
[Ex-Mitglied]
24.10.2007, 18:36 Uhr [ - Direktlink - ] |
Thema: Keyboard und Maus über PS/2-USB Adapter am USB Port
Brett: Amiga, AmigaOS 4 Zitat: Probier doch mal ein anderes LoadModule, z.B. das von THOR. Hast Du sonst irgendwelche Tools laufen, die ggf. die Reset-Vektoren löschen oder verbiegen? Was sagt Scout zum Thema "Residents"? -- -- Best Regards Chris Hodges |
|||||
platon42
[Ex-Mitglied]
24.10.2007, 18:05 Uhr [ - Direktlink - ] |
Thema: Keyboard und Maus über PS/2-USB Adapter am USB Port
Brett: Amiga, AmigaOS 4 @julius: Meine Vermutung ist, dass irgendwas mit dem Einbinden des input.device' nicht klappt. "version input.device FULL" nach dem Booten gibt da genaue Auskunft. Steht da V50.x und geht Keyrepeat trotzdem nicht, dann ist irgendetwas anderes faul. An OS 3.1 allein kann es eigentlich nicht liegen, ich selbst verwende auch nur OS 3.1. -- -- Best Regards Chris Hodges |
|||||
platon42
[Ex-Mitglied]
22.10.2007, 22:42 Uhr [ - Direktlink - ] |
Thema: Keyboard und Maus über PS/2-USB Adapter am USB Port
Brett: Amiga, AmigaOS 4 Zitat: Die neueren Versionen der HID.class lassen sich ebenfalls resetfest einbinden. Ansonsten kannst Du auch mit den kleineren bootmouse und bootkeyboard Klassen vorlieb nehmen. Wie auch schon hunderte Male vorher geschrieben (sorry), muss das neue input.device resetfest eingebunden sein, sowie das neue bootmenu von OS3.9 BoingBag 2. Bei Funkmäusen müssen auch noch im richtigen Moment die Maustasten gedrückt werden. -- -- Best Regards Chris Hodges |
|||||
platon42
[Ex-Mitglied]
22.10.2007, 22:39 Uhr [ - Direktlink - ] |
Thema: Keyboard und Maus über PS/2-USB Adapter am USB Port
Brett: Amiga, AmigaOS 4 Zitat: Weil Du beim einen System das neue input.device resetfest oder im FlashRom hast und beim anderen nicht? -- -- Best Regards Chris Hodges |
|||||
platon42
[Ex-Mitglied]
13.10.2007, 17:11 Uhr [ - Direktlink - ] |
Thema: Registerzugriff in C
Brett: Programmierung @MaikG: Das timer.device ist fürs Warten, es wartet mindestens so lange wie angegeben. Aber: Für regelmäßige, kurze Intervalle ist das ungeeignet. Wenn Du das willst, verwende die realtime.library oder eben die lowlevel.library für den CIA-Timer. Du wirst mit diesen Task-Polling-Schleifen nichts Vernünftiges hinbekommen. Ever. -- -- Best Regards Chris Hodges |
|||||
platon42
[Ex-Mitglied]
11.10.2007, 22:31 Uhr [ - Direktlink - ] |
Thema: Registerzugriff in C
Brett: Programmierung Zitat: Der Code ist SAS/C kompatibel. Welche "neueren Sachen" sollte er denn nicht können? Zitat: Die LowLevel-Library bietet ein paar sehr einfache Funktionen, um CIA-Timer-Interrupts einzubinden. Und das timer.device ist mit UNIT_MICROHZ recht akzeptabel -- leider bei mir nicht 100% regelmäßig. Zitat: Seltsam. Selbst ein 68000er ist fähig, mit mehr als 28000Hz zu samplen. Zumindest in ASM. -- -- Best Regards Chris Hodges |
|||||
platon42
[Ex-Mitglied]
11.10.2007, 18:15 Uhr [ - Direktlink - ] |
Thema: Registerzugriff in C
Brett: Programmierung Zitat: Du solltest von Hardware-Registern die Finger lassen, zumindest mit OS-Funktionen wie CopyMem, denn Du weißt nicht, was der damit macht (es gibt keine Garantie, dass der da jetzt byteweise zugreift). Und MEMF_FAST ist eine Unsitte, bitte gleich streichen. Außerdem solltest Du vorher mit der ciaa.resource die Portbits allokieren und später wieder freigeben. Richtigerweise sollte das eher so aussehen: code:include <hardware/cia.h> UBYTE *buffer; // du willst keine ULONGs, oder? // hardware register sind unbedingt als volatile zu kennzeichnen, // sonst optimiert der compiler dir den zugriff weg! volatile struct CIA *ciaa = (volatile struct CIA *) 0xbfe001; // das ist ne optimierung... aber prinzipiell könntest // Du unten auch mit x = ciaa->ciaprb arbeiten volatile UBYTE *ciaaportb = &ciaa->ciaprb; ULONG cnt = 120000; UBYTE *targetptr; // wenn du nicht im interrupt läufst. Wenn Du später mal deine // Auslese mit exaktem Timing brauchst, wirst Du das sicher in // einen Interrupt auslagern, dann sollte MEMF_PUBLIC gesetzt sein targetptr = buffer = (UBYTE *) AllocVec(120000, 0); do { *targetptr++ = *ciaaportb - 127; // -127? Thilo hatte bei sich -128 (0x80) stehen. // do while(), nur wenn du weißt, dass cnt sicher größer als 0 // ist (wie in diesem Fall); eine while() {} schleife erzeugt // teilweise schlechteren code, ebenso eine "vorwärtsschleife" // mit cnt = 0; cnt < 120000; cnt++) } while(--cnt); ciaa->ciaddrb = 0x55; // 0xbfe301 beschreiben -- Best Regards Chris Hodges [ Dieser Beitrag wurde von platon42 am 11.10.2007 um 18:18 Uhr geändert. ] |
|||||
platon42
[Ex-Mitglied]
11.10.2007, 17:55 Uhr [ - Direktlink - ] |
Thema: Adapter PS2 auf USB
Brett: Amiga, AmigaOS 4 Zitat: Meine Vermutung ist, dass dieser da geht: http://www.pearl.de/p/PE8498-USB-PS-2-Adapter.html -- -- Best Regards Chris Hodges |
|||||
platon42
[Ex-Mitglied]
06.10.2007, 10:42 Uhr [ - Direktlink - ] |
Thema: Commodities.library - Übersicht input description strings ?
Brett: Programmierung @p-OS: MorphOS unterstützt einen neuen EventType IECLASS_EXTRAWKEY für extended Raw-Keys, die im Großen und Ganzen den PS/2 extended raw keys entsprechen. Mit der HID-Klasse aus Poseidon 3.8 werden diese sogar standardmäßig für einige Multimedia-Keys erzeugt und gemappt, auch wenn die wahrscheinlich unter AmigaOS bisher nicht wirklich unterstützt werden. -- -- Best Regards Chris Hodges |
|||||
platon42
[Ex-Mitglied]
06.10.2007, 10:35 Uhr [ - Direktlink - ] |
Thema: Commodities.library - Übersicht input description strings ?
Brett: Programmierung Zitat: Nein. Bis auf die lowlevel.library Patches wird von Poseidon nichts gepatcht. Und die Bezeichner in der GUI stammen bis auf einige wenige Ausnahmen (die sonst nicht wirklich aussagekräftig wären) aus der Funktion MapRawKey() der keymap.library. -- -- Best Regards Chris Hodges |
|||||
platon42
[Ex-Mitglied]
19.09.2007, 22:14 Uhr [ - Direktlink - ] |
Thema: maprom auf cs060 mk1
Brett: Amiga, AmigaOS 4 @wawa: Es funktioniert, und ich habe auch erst ein paar Jahre gebraucht, bevor ich herausgefunden habe, wie (und es ging auch nicht mit allen BlizKick-Versionen). Wichtig ist: Du brauchst Mainboard-RAM. Und bei BlizKick musst Du "CPUCARD" mit angeben, weil er nicht automatisch die MK I findet. -- -- Best Regards Chris Hodges |
|||||
platon42
[Ex-Mitglied]
11.09.2007, 22:54 Uhr [ - Direktlink - ] |
Thema: Poseidon/Trident: nak timeouts
Brett: Amiga, AmigaOS 4 @Sprocki: Probiers mal mit "Compatibility Hack for broken host controller drivers". -- -- Best Regards Chris Hodges |
|||||
platon42
[Ex-Mitglied]
07.08.2007, 09:42 Uhr [ - Direktlink - ] |
Thema: Läuft USB-Festplatte an Autoradio?
Brett: Andere Systeme Zitat: Hat bei mir nicht wirklich gut funktioniert (irgendsoein Noname-Autoradio für 100 EUR), denn anscheinend haben die Nulpen kein Buffering eingebaut, d.h. jedes Mal, wenn auf der Platte geseekt werden musste, kam es zu höherer Datenübertragungslatenz und die Musik setzte kurz aus. Ähnlich verhält es sich bei meinem DVD Player mit USB Port :-( -- -- Best Regards Chris Hodges |
|||||
platon42
[Ex-Mitglied]
21.07.2007, 13:23 Uhr [ - Direktlink - ] |
Thema: Kickflash
Brett: Amiga, AmigaOS 4 Zitat: Die Erweiterung der Kickflash ist nie erschienen. AFAIK sollte der Linux-Kernel (nur der Kernel!) mit Kompression aber locker ins Flashrom passen. Müsste sich nur jemand finden, der sich für solch ein Projekt interessiert und ein RomTag dafür baut. -- -- Best Regards Chris Hodges |
|||||
platon42
[Ex-Mitglied]
14.07.2007, 11:01 Uhr [ - Direktlink - ] |
Thema: Spider spinnt !
Brett: Amiga, AmigaOS 4 Zitat: IMHO: Dat Ding is kaputt. -- -- Best Regards Chris Hodges |
|||||
platon42
[Ex-Mitglied]
09.07.2007, 19:57 Uhr [ - Direktlink - ] |
Thema: Auflösung CV64
Brett: Amiga, AmigaOS 4 Zitat: Mit Deinen Einstellungen bekomme ich zwar ein Bild, kann aber horizontal nicht genug quetschen, sprich, es zeigt nicht die volle Breite an. Zitat: http://www.amiga-news.de/forum/thread.php?id=25527&start=post&postid=257483&BoardID=1 -- -- Best Regards Chris Hodges |
|||||
platon42
[Ex-Mitglied]
09.07.2007, 09:11 Uhr [ - Direktlink - ] |
Thema: Auflösung CV64
Brett: Amiga, AmigaOS 4 Zitat: Ohne Interlace wirst Du wohl nicht auf 60 Hz kommen, ohne die MEMCLOCK auf 53 oder mehr MHz zu erhöhen (was aber zu ner Menge Grafikfehler bei mir führt). Ging aber auch schon, mein altes TFT sync'te erst ab so ca. 55 Hz. Zum Glück sync't mein aktuelles TFT bei 50Hz darum verwende ich derzeit (laut TFT): 53.54KHz x 50.41Hz mit einer Pixelclock von 90.37 MHz bei 50MHz MemClock. Für 8/16 Bit: Pixelclock 90020000Hz, Horizontale Werte: Auflösung 1280, Synclänge 408, Pulsabstand 48, Pulslänge 112, Polarität positiv. Vertikal: 1024, Sync 42, Pulsabstand 1, Pulslänge 3, Polarität positiv. Kommt laut CGXMode auf ungefähr 53.33kHz, 50.03Hz. -- -- Best Regards Chris Hodges |
|||||
platon42
[Ex-Mitglied]
18.06.2007, 19:41 Uhr [ - Direktlink - ] |
Thema: gibt es kickstart-modifikationen?
Brett: Amiga, AmigaOS 4 Zitat: Wenn wir das selbe meinen, ist das doch nur ein Kompatibilitätshack für alte Kick 1.3 Programme, die unbedingt in $FC0000 für Reset-Routinen einspringen wollten. Ich glaube nicht, dass man heutzutage dieses Feature noch *irgendwo* braucht, gerade, wenn es sich um Kick 3.1+ ROMs handelt. -- -- Best Regards Chris Hodges |
|||||
platon42
[Ex-Mitglied]
10.06.2007, 10:47 Uhr [ - Direktlink - ] |
Thema: ich will mein Poseidon V 2.2 wieder
Brett: Amiga, AmigaOS 4 Zitat: Verwirrend? Er ist voller Fehler (4MB/sec bei einer Subway? Vielleicht sollte der "Tester" mal das Caching-Programm abschalten), und ziemlich inhaltsleer! Die arme Total Amiga -- ich erwarte nichts Gutes... :-( -- -- Best Regards Chris Hodges |
|||||
platon42
[Ex-Mitglied]
10.06.2007, 10:45 Uhr [ - Direktlink - ] |
Thema: ich will mein Poseidon V 2.2 wieder
Brett: Amiga, AmigaOS 4 Zitat: Wichtig ist auch ENVARC:PsdStackloader zu löschen oder das Backup davon einzuspielen, wie es bei der Installation von V3.x empfohlen wird. -- -- Best Regards Chris Hodges |
|||||
platon42
[Ex-Mitglied]
03.06.2007, 19:28 Uhr [ - Direktlink - ] |
Thema: Neues OS4 Lame bringt Rekordspeed!!!
Brett: MorphOS Zitat: Tatsächlich: Seit 3.98beta1 ist -k defaultmäßig aktiviert. Lustig ist dabei, dass in der Auflistung der Kommandozeilenoptionen immer noch "not recommended" drin steht (ja, höchstens für CBR). Wenn natürlich der Tiefpassfilter in der neuen Version automatisch deaktiviert ist, kann das auch einige Geschwindigkeitsunterschiede erklären. -- -- Best Regards Chris Hodges |
|||||
platon42
[Ex-Mitglied]
03.06.2007, 15:33 Uhr [ - Direktlink - ] |
Thema: Thumbnail-Programm für amigaOS
Brett: Amiga, AmigaOS 4 @Honitos: Die schnellste Methode, thumbnails zu erzeugen, ist immer noch djpeg mit -scale 1/4 oder 1/8. Alle andere Methoden, die das Bild in 1:1 Auflösung decodieren, statt bereits bei der IDCT-Transformation die Ausgabematrix zu reduzieren, können nur langsamer sein. -- -- Best Regards Chris Hodges |
|||||
platon42
[Ex-Mitglied]
03.06.2007, 15:29 Uhr [ - Direktlink - ] |
Thema: Neues OS4 Lame bringt Rekordspeed!!!
Brett: MorphOS Zitat: Ouch. Das ist ja hier wie beim Monte Carlo-Prinzip. Einfach mal ins Blau feuern, vielleicht fällt ja die richtige Antwort vom Himmel. An den Bändern ändert sich rein gar nichts. -q0 und -q1 wählen nur andere Algorithmen aus (nicht nur auf FFT beschränkt), die verschieden genau arbeiten. Manchmal hilft es schon, die Docs zu lesen. Manchmal muss man sich aber auch durch den Sourcecode quälen, um die Wahrheit zu finden. -- -- Best Regards Chris Hodges |
|||||
platon42
[Ex-Mitglied]
03.06.2007, 10:55 Uhr [ - Direktlink - ] |
Thema: Neues OS4 Lame bringt Rekordspeed!!!
Brett: MorphOS Zitat: Halte ich für ein Gerücht. Da kann man ziemlich streng nach psychoakkustischem Modell vorgehen und die Bits auf die Bänder verteilen. Ach ja, ich halte diese ganze Diskussion für müßig ohne definierte Testbedingungen, sowohl für das Input-Material, Compiler-Einstellungen, #defines für LAME etc. Wenn ihr wirklich Geschwindigkeitsgewinn ohne Qualitätsunterschied haben wolltet, hättet ihr längst --noreplaygain verwendet. Ach ja, meine Einstellungen: --noreplaygain -p -h -k -v -V 5 -q 1 --vbr-old --nspsytune --athtype 2 Ich traue dem --vbr-new nicht, da ich teilweise bei einigen Songs einen Faktor 2 Unterschied in der durchschnittlichen Bitrate hatte. Und wer MP3s ohne -k encodiert ist selber Schuld. -- -- Best Regards Chris Hodges |
|||||
platon42
[Ex-Mitglied]
20.05.2007, 22:36 Uhr [ - Direktlink - ] |
Thema: SoundFX
Brett: Amiga, AmigaOS 4 Zitat: Falls Du Deine Konfig nicht löschen willst, probiers doch mit NewMode. -- -- Best Regards Chris Hodges |
|||||
platon42
[Ex-Mitglied]
20.05.2007, 22:35 Uhr [ - Direktlink - ] |
Thema: Festplattenbackup
Brett: Amiga, AmigaOS 4 @mistral: Wenn die Amiga Platte FFS formatiert ist mit RDB und so solltest Du am PC Linux verwenden und zwar das "dd" Kommando. Damit kannst Du ein Image der Platte erstellen. Damit das auch als Backup taugt, muss die Platte, auf die Du das zurückspielst, mindestens die gleiche Größe haben. Mit Windows kommst Du mit Standardmitteln erst gar nicht an die Roh-Daten ran. Du kannst das dann erzeugte Backup-Image übrigens auch unter Linux mounten (wenns FFS formatiert ist, mit SFS und PFS kommt Du nicht weiter). WinUAE kann auch mit solchen HD-Images umgehen AFAIK. -- -- Best Regards Chris Hodges |
|||||
platon42
[Ex-Mitglied]
18.05.2007, 00:04 Uhr [ - Direktlink - ] |
Thema: Audio CD Brennen mit MakeCD
Brett: Amiga, AmigaOS 4 Zitat: Keine Ahnung. Die libmad-Version war bei mir immer unspielbar langsamer. -- -- Best Regards Chris Hodges |
|||||
platon42
[Ex-Mitglied]
17.05.2007, 21:37 Uhr [ - Direktlink - ] |
Thema: Audio CD Brennen mit MakeCD
Brett: Amiga, AmigaOS 4 Zitat: Hier noch ein kleiner Hinweis meinerseits: Wenn das MP3 mit VBR (Variabler BitRate) encodiert ist, kann es passieren, dass die mpega.library bzw. MakeCD die Länge nicht korrekt berechnet und das MP3 abschneidet. Da hilft nur noch, das MP3 vorher zu dekodieren. Gibt zu diesem Zweck ein angepasstes Shell-Programm namens mpdec (Original von Thomas Wenzel) auf Anfrage. -- -- Best Regards Chris Hodges |
|||||
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |