amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > Datei Decodieren [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- 2 [ - Beitrag schreiben - ]

10.01.2006, 18:52 Uhr

MaikG
Posts: 5172
Nutzer
Ich hab hier eine Datei, die war mit 2 Packern gepackt.
Der 2. ware geschützt, den schutz konnte ich entfehrnen.
Fertig - dachte ich, aber die Datei ist nochmal in sich Codiert.
Sigfried erkennt eine decodier/codier routine. Leider kann
ich mit sowas nicht viel anfangen. In Assembler bin ich nicht
so bewandert, der Code ist dieser:

LB_7DC0 DC $9FFD
DC $ECFE
CMP.B D5,D3
ORI.B #$B3,D5
LINE_F #$05A1
ADDX.L D7,D1
LINE_F #$0FFB
ADD.L ([$B7187F7F.L],D7.W*4),D3
DC $8FFF
BFINS D0,D5{$00:$19}
EXTB.L D3
LINE_F #$0FDF
SUBA.L $1CB7(A5),A5
LINE_F #$097F
LINE_F #$0F20
MOVES.W A3,
LINE_F #$074B
ABCD.B D3,D7
DC $CC3F
DC $DF7F
DC $8FFF
CMP.B D5,D6
LINE_F #$058C
EOR.W D0,(A1)
ANDI.B #$BF,-(A7)
LINE_F #$059D
EOR.W D0,(A1)
ORI.L #$BC05F56D,D3
EOR.W D0,(A1)
BTST D0,-(A5)
DC $B57F
SUBA.W ([$DD97FFF5.L],D5.L*8,$ED43FFAC.L),A4
ADD.L ([$B1510089.L],D7.W*4),D3
BGE.B LB_7E5E
EOR.W D0,(A1)
BTST D0,-(A5)
DC $DFBF
DC $D6BF
LINE_F #$0589
ADD.L (A7),D3
LINE_F #$0FF5
LINE_F #$0591
CMP.B D5,D6
LINE_F #$059D
ADD.L ([$B593F5A3.L]),D7
SUBA.L A1,A4
EOR.W D2,(A7)
LINE_F #$0F53
SUBA.L A7,A4
CMP.B (A7),D7
LINE_F #$0FA3
ADDA.W ([$017FDFA0.L,A7]),A0
EOR.W D0,(A1)
BCHG D0,-$41(A3,A5.W*8)
LB_7E5E LINE_F #$0599
SUBA.W -(A5),A4
DC $DFBF
ADDA.L (A7),A7
LINE_F #$0FDB
SUBA.W -$2041(A5),A4
ADDA.L -$670D(A7),A6

Wie bekomme ich die Datei decodiert?

[ - Antworten - Zitieren - Direktlink - ]

10.01.2006, 20:13 Uhr

thomas
Posts: 7716
Nutzer
Zitat:
In Assembler bin ich nicht so bewandert, der Code ist dieser:

Das ist kein Programm, sondern nur Assembler-Befehle unsinning aneinandergereiht.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

10.01.2006, 23:22 Uhr

MaikG
Posts: 5172
Nutzer
>Das ist kein Programm, sondern nur Assembler-Befehle
>unsinning aneinandergereiht.

Das ist Dissassemblert, am anfang der Executable steht
ein Code Hunk. Da muss gleich die decodierung kommen
(Sigfried liesst ja auch nur 1024 Bytes ein und erkennt
die decodier routine).

[ - Antworten - Zitieren - Direktlink - ]

11.01.2006, 08:50 Uhr

thomas
Posts: 7716
Nutzer
Zitat:
Original von MaikG:
Das ist Dissassemblert,


Ich weiß, was das ist. Ich kann sowas sogar schreiben.

Zitat:
am anfang der Executable steht
ein Code Hunk.


Das mag ja sein, aber in dem Code-Hunk ist kein Code drin.

Zitat:
Da muss gleich die decodierung kommen

Dann weiß sie (die Dekodierung) aber nichts davon. Das da oben gibt jedenfalls einen netten Absturz, nicht mehr.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

11.01.2006, 10:01 Uhr

MaikG
Posts: 5172
Nutzer
>Ich weiß, was das ist. Ich kann sowas sogar schreiben.

Ich sag ja nur weil assembler Source anders aussieht.

>Das mag ja sein, aber in dem Code-Hunk ist kein Code drin.

Wo soll der sonst sein? AOS ladet zuerst den ersten Code
Hunk, wenn dort nichts sinnvolles stehen würde könnte das
Programm nicht decodiert werden.


>Dann weiß sie (die Dekodierung) aber nichts davon. Das
>da oben gibt jedenfalls einen netten Absturz, nicht mehr.

Das Programm stürzt wirklich ab(80000004), es war mit Titanicscruncher
gepackt. Bei dem werden Data Hunks zu Code Hunks, ich dachte
deswegen stürzt das ab. Oder weil der Code merk das er entpackt
wurde.
Mir würde auch ein Decodierprogramm helfen das Additionen, Subtaktionen
und XOR etc. durchführt und guckt ob irgendwann library oder Font
im Code vorkommt - hab aber keins im Aminet gefunden.


[ - Antworten - Zitieren - Direktlink - ]

11.01.2006, 12:12 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von MaikG:
Mir würde auch ein Decodierprogramm helfen das Additionen, Subtaktionen
und XOR etc. durchführt und guckt ob irgendwann library oder Font
im Code vorkommt - hab aber keins im Aminet gefunden.


Was genau willst Du machen?

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

11.01.2006, 18:44 Uhr

MaikG
Posts: 5172
Nutzer
>Was genau willst Du machen?

Die Datei Decodieren um sie Patchen zu können.
Es werden von dem Programm sachen ins FastRam geladen,
die ins Chipram müssen, die Tastaturbelegung ist USA
und soll Deutsch, dann noch weitere Bugs die aber komplizierter
zu lösen sind.
Das Programm wurde in AMOS geschrieben.

[ - Antworten - Zitieren - Direktlink - ]

11.01.2006, 18:48 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von MaikG:
Die Datei Decodieren um sie Patchen zu können.
Es werden von dem Programm sachen ins FastRam geladen,
die ins Chipram müssen, die Tastaturbelegung ist USA
und soll Deutsch, dann noch weitere Bugs die aber komplizierter
zu lösen sind.
Das Programm wurde in AMOS geschrieben.


Da hast Du Dir ja viel vorgenommen...

Starte NoFastMem vorher und leb mit den anderen Bugs.
Oder versuch den Source-Code zu bekommen,
oder schmeiß das Programm in die Tonne.

Sorry, aber ne bessere Antwort is da echt nicht möglich.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

11.01.2006, 19:18 Uhr

MaikG
Posts: 5172
Nutzer
>Da hast Du Dir ja viel vorgenommen...

Die Bugs beseitigen ist nicht das Problem, das Decodieren
schon.

>Starte NoFastMem vorher und leb mit den anderen Bugs.

Mit dem Programm benötige ich meist schon 100 MB Fastmem zum
arbeiten.

>Oder versuch den Source-Code zu bekommen,

Finde keine Email vom Author.

>oder schmeiß das Programm in die Tonne.

Kein guter Ersatz vorhanden.

[ - Antworten - Zitieren - Direktlink - ]

12.01.2006, 12:35 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von MaikG:
Das Programm wurde in AMOS geschrieben.


Da wäre es aber sehr viel einfacher, den Source Code des AMOS Programms anzuschauen, als den Maschinencode durch einen Disassembler zu jagen...

--

http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

12.01.2006, 13:44 Uhr

thomas
Posts: 7716
Nutzer
@MaikG:

Ich verstehe sowieso nicht, wie du das Programm verändern willst, wenn du noch nichtmal die Assembler-Liste lesen kannst. Den AMOS-Code wirst du nicht bekommen, so oft du es auch disassemblierst.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

12.01.2006, 18:47 Uhr

MaikG
Posts: 5172
Nutzer
>Da wäre es aber sehr viel einfacher, den Source Code des
>AMOS Programms anzuschauen, als den Maschinencode durch
>einen Disassembler zu jagen...

Wenn ich den Sourcecode hätte...


>@MaikG:
>Ich verstehe sowieso nicht, wie du das Programm
>verändern willst, wenn du noch nichtmal die Assembler-Liste
>lesen kannst. Den AMOS-Code wirst du nicht bekommen, so
>oft du es auch disassemblierst.

Ich weiss, das aus Assembler nicht AMOS, C oder Basic
werden kann.
Aber ich weiss wie ein AllocMem/AllocVec unter Assembler aussieht
und man den dazu bringt statt PublicMem ChipMem zu nehmen.
Die Routine mit dem QUERY hab ich auch gefunden, das Y->Z
zu setzten ist auch kein Problem. Hab mit das Programm
aus dem Speicher gegrabt, leider ist es da keine Executable
mehr(Mit Hunks) und ob das zusammenhängend ist weiss ich nicht.

[ - Antworten - Zitieren - Direktlink - ]

12.01.2006, 23:53 Uhr

DOM
Posts: 1044
Nutzer
Hehe, dass erinnert mich an Programme, die ich mal geschrieben hatte.
Aber egal, checke das Programm als erstes mit Powerpacker und was der
sagt. Falls er es entpacken kann, speichere dieses und schau dir den
Code in einem Hex-Editor oder CED etc. an, wenn auf der ersten Seite
was lesbares zu finden ist, etwa ein Name, dann wurde es z.B. mit
Hunklab bearbeitet, oder ein dummer Assembler-Dummy-Code vorgeschoben,
wenn nicht, dann sollte man es nochmals mit einem Programm, wie etwa
den Powerpacker laden und entpacken, bis es im lesbaren Format vor-
liegt und danach kann man es durch Resource jagen, oder einfach den
Loader (falls es AMOS ist) mit nem Editor entfernen...
Noch einfacher geht es allerdings, wenn man das Programm startet und
mit nem Memory-Editor speichert und das natürlich bei einem minimal
System mit wenig Speicherzugriffen und wenn die Hunks dann immer
noch fehlen, würde ich wirklich auf Hunklab in Verbindung mit
Powerpacker tippen...

[ Dieser Beitrag wurde von DOM am 13.01.2006 um 00:03 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

13.01.2006, 14:46 Uhr

MaikG
Posts: 5172
Nutzer
>Hehe, dass erinnert mich an Programme, die ich mal
>geschrieben hatte.
>Aber egal, checke das Programm als erstes mit Powerpacker
>und was der sagt.

Ist nicht Powerpacker gepackt, die Datei ist jetzt wirklich
nicht mehr gepackt. Den ersten Packer weiss ich nicht mehr,
der 2.Packer war Titaniccruncher. Das letzte hat der Author
im About verraten.
Eventuell hat der Author ein verschlüsselungsprogramm verwendet
und es nicht selbst gemacht.
Reminder von Damon
Amiga "E" von Wouter
und FlashDisk von Nitewing
stehen noch im About, habe kein Programm von denen gefunden,
vielleicht ist eines davon ein Verschlüsselungsprogramm.


>Noch einfacher geht es allerdings, wenn man das Programm startet und
>mit nem Memory-Editor speichert und das natürlich bei einem minimal
>System mit wenig Speicherzugriffen und wenn die Hunks dann immer
>noch fehlen, würde ich wirklich auf Hunklab in Verbindung mit
>Powerpacker tippen...

Müssten die Hunks im Speicher sein? Ich meine bei einem Normalen Programm?
Ich hab ja schon gegrabbt aber kein $03F3 gefunden.

Hab den Codeanfang mal durch die Texterkennung gejagt:

000003F300000000000000080000000000000001400002BD
40011E1B400010B6400011A1400004854000020E40000200
40000061000003E9000002BD9FFDE1FEB6050005D6B3F5A1
D381FFFBD6B0F595B1181F1F8FFFEF1500194F13FFDF9BED
11B1F91FFF200E1FBE05F14B1F03113FDF1F8FFFB105F581
B1510221D6BFF59DB1510083B105F56DB1510125B51F98F1
DFBFDD91FFF5ED43FFA1D6B6F58DB15100896136B1510125
DFBFD6BFF589D691FFF5F591B105F59DDEB6FFF5B593F5A3
9919B551FF53991FBE11FFA3D0F1B151011FDFA0B1510113
D6BFF59998E5DFBFDFD1FFDB98EDDFBFDDEF98F3D385F64F
B151001DD381FFFBB205F11F9EFFF8D994FFF145DBB69EFF
F8E394FFF14FD9B69EFFFA699EFFF841AF119EFFF8F194FF
F163D9B69EFFF90194FFF16DDBB6D113FFFFF6FF2154FFF1
2155FFFB2155FFF1DFF8DD13FFFEFFFE9EFFFAD998FFF191
D3FFD5BFB412F6FFDFB22414FFF1BE11001FD4B1F9FBBE11
0013D4B1F9FFBE110011D4B1F161BE110055D4B1FD2FBE11
0011D4B1FD41BE11000FD4B1FB11BE11000BD4B1FB1BBE11
00D1D4B1FB83BE110003D4B1FB1FBE110013D4B1FB81BE11
006BD4B1FB8BBE11006BD4B1FB2DBE1100FFD4B1FB31BE11
03FFD4B1FB39D4B1F955DF13FFFFFEFFDD13FFFEFFFE9EFF
FB6F98FFFD21D4BFFB8FD493F589001BDDB22115FFFBDFD5
FFF1A11FBA15FFF3ED25AE3100039EFFF939D339D338DFB2
2F12F48D9EFFF9F194FFFD5DBA12F19D8FF01B26AE310003
D4B6158D9EFFFA0994FFFE1BD4B600239EFFFA1594FFFE21
D4B6199DB812FB1BD4B4F1E9D6B1F5A99EFFFA2D94FFFE3F
98F99EFFFB1D9F0FD485F113F9DFD381FFFB8FFFB105F166
B1510221D4BF18AD98FFFE63D381FFFB8FDAD9FFB105F190

[ - Antworten - Zitieren - Direktlink - ]

13.01.2006, 17:49 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von MaikG:
Ich hab ja schon gegrabbt aber kein $03F3 gefunden.

Hab den Codeanfang mal durch die Texterkennung gejagt:

000003F300000000000000080000000000000001400002BD
40011E1B400010B6400011A1400004854000020E40000200


1. Ein Hexdump is keine "Text-Erkennung"
2. Wenn Du kein 3F3 gefunden hast, hmm, ich sehe auf den ersten Blick eines
3. Nichts gegen Blinde, aber einen Führerschein können sie nunmal nicht machen.
Es würde Monate bis Jahre brauchen, um Dir zu erklären, was Du da eigentlich tust, und das mit zweifelhaften Nutzen.

Du hast nämlich immer noch nicht erwähnt, was das denn für eine tolle Software sein soll, die trotz der von Dir aufgezählten Probleme eine solchen Aufwand wert sein soll.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

13.01.2006, 17:54 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von MaikG:
...
Amiga "E" von Wouter
...
stehen noch im About, ...


... und Du bist Dir sicher, daß das Programm in AMOS geschrieben wurde?
Vielleicht solltest Du mal die Begriffe Amiga E Wouter einfach nur in google eingeben.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

13.01.2006, 18:45 Uhr

MaikG
Posts: 5172
Nutzer
>1. Ein Hexdump is keine "Text-Erkennung"

Der Hexeditor den ich benutze kann das nicht Speichern,
daher habe ich den Screen gegrabt und durch die Texterkennung
gejagt.

>2. Wenn Du kein 3F3 gefunden hast, hmm, ich sehe auf den
>ersten Blick eines

Das ist die Executable(1.Hunk-Decodierroutine), nicht der Grab aus
dem Speicher.

>Du hast nämlich immer noch nicht erwähnt, was das denn für
>eine tolle Software sein soll, die trotz der von Dir
>aufgezählten Probleme eine solchen Aufwand wert sein soll.

Megalosound - Samplebearbeitungssoftware die mit der
gleichnamigen Hardware kommt. Ist von 1993. Samplemanager
kommt dem nahe, arbeitet intern aber immer mit 16Bit. Von
daher kann ich damit nur einen halb so großen Sample laden.
Die Wiedergabe Qualität ist auch nicht die selbe.

>... und Du bist Dir sicher, daß das Programm in AMOS geschrieben
>wurde?
>Vielleicht solltest Du mal die Begriffe Amiga E Wouter einfach
>nur in google eingeben.

Ja, da AMOS Tasks im Speicher sind nach dem Programmstart.
Amiga E - Die Programmiersprache hab ich auch hier.
Aber auf die Programmiersprache kommt es nicht an, die änderungen
mache ich im Hexeditor wenn ich das Programm entschlüsselt bekomme.

[ - Antworten - Zitieren - Direktlink - ]

13.01.2006, 20:10 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von MaikG:
Das ist die Executable(1.Hunk-Decodierroutine), nicht der Grab aus
dem Speicher.

Na im Speicher wirst Du die $3f3 Kennungen auch nicht finden.
Zitat:
Ja, da AMOS Tasks im Speicher sind nach dem Programmstart.
Amiga E - Die Programmiersprache hab ich auch hier.

Dann solltest Du wissen, daß es kein Verschlüsselungsprogramm ist.
Tip: auch die anderen Programme sind keine Verschlüsselungsprogramme.
Zitat:
Aber auf die Programmiersprache kommt es nicht an, die änderungen
mache ich im Hexeditor wenn ich das Programm entschlüsselt bekomme.

Du mußt es ja wissen...

Kleiner Tip: vielleicht ist es ja einfacher, ein Programm zu schreiben, daß Megalosound startet und dann im Speicher patcht, statt etwas entschlüsseln zu wollen, daß am Ende vielleicht gar nicht verschlüsselt ist.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

13.01.2006, 23:47 Uhr

MaikG
Posts: 5172
Nutzer
>Na im Speicher wirst Du die $3f3 Kennungen auch nicht
>finden.

Dachte ich mir, das OS ließt den Hunk, setzt das Programm
an eine freie Speicherstelle und dann wird ja die Kennung
nicht mehr benötigt.

>Dann solltest Du wissen, daß es kein Verschlüsselungsprogramm ist.
>Tip: auch die anderen Programme sind keine Verschlüsselungsprogramme.

Ich meine ja nur wenn er den Hinweis auf Titanicscruncher gibt,
hätte es auch sein können das er auf ein Verschlüsselungstool
hinweisst. Vielleicht hat er die Routine auch selbst geschrieben.


>> Aber auf die Programmiersprache kommt es nicht an, die änderungen
>> mache ich im Hexeditor wenn ich das Programm entschlüsselt bekomme.
>Du mußt es ja wissen...

Ob E, Basic, C oder AMOS ein AllocMem/AllocVec sieht ziemlich gleich
aus im Hexeditor.

>Kleiner Tip: vielleicht ist es ja einfacher, ein Programm zu
>schreiben, daß Megalosound startet und dann im Speicher patcht,

Schon, einfacher aber das ist nicht nach den Richtlinen, verursacht
bestimmt Enforcer Hits und stürzt ggf. unter OS4 wegen dem Speicherschutz
ab.

>statt etwas entschlüsseln zu wollen, daß am Ende vielleicht gar
>nicht verschlüsselt ist.

Ich weiss das Megalosound librarys+fonts öffnet, das Wort Megalosound
und diverse andere enthalten sind - aber nichts davon, kein lesbares
Wort ist im Hexeditor zu lesen. Von daher muss das Programm Verschlüsselt
sein.

[ - Antworten - Zitieren - Direktlink - ]

14.01.2006, 16:52 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von MaikG:
>Kleiner Tip: vielleicht ist es ja einfacher, ein Programm zu
>schreiben, daß Megalosound startet und dann im Speicher patcht,

Schon, einfacher aber das ist nicht nach den Richtlinen, verursacht
bestimmt Enforcer Hits und stürzt ggf. unter OS4 wegen dem Speicherschutz ab.

Quatsch.
Ein anderes Programm (genaugenommen hunk-Objekt) quasi als Unterprogramm zu laden, ist eine ganz legale Aktion, die auch von anderen Programmen so duchgeführt wird, z.B. div. Maxon-Programme bestehen aus solchen Einheiten.
Abgesehen davon, daß das ganze Amiga-Library+Devices System so funktioniert.

Enforcer registriert nur Zugriffe auf unbenutzten oder nicht existenten Speicher und das ist auch das maximale was ein AOS4-Speicherschutz, so es ihn denn gäbe, im Kompatiblitätsmodus für 68k-Programme schützen kann.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

14.01.2006, 18:13 Uhr

MaikG
Posts: 5172
Nutzer
>Enforcer registriert nur Zugriffe auf unbenutzten oder
>nicht existenten Speicher und das ist auch das maximale
>was ein AOS4-Speicherschutz, so es ihn denn gäbe, im
>Kompatiblitätsmodus für 68k-Programme schützen kann.

Man kann also sagen wir mit Programm "Patch" in einem
Speicherbereich schreiben der aber von Programm "Megalosound"
allociert wurde?

[ - Antworten - Zitieren - Direktlink - ]

14.01.2006, 18:43 Uhr

thomas
Posts: 7716
Nutzer
@MaikG:

Zitat:
Man kann also sagen wir mit Programm "Patch" in einem
Speicherbereich schreiben der aber von Programm "Megalosound"
allociert wurde?


Yep. Sonst würde das komplette Message-System des AmigaOS nicht funktionieren. Dabei werden nämlich nur Pointer weitergegeben, kein Speicher kopiert.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

16.01.2006, 08:21 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Es werden von dem Programm sachen ins FastRam geladen,
die ins Chipram müssen,


Wie kommst Du darauf?

Zitat:
Megalosound - Samplebearbeitungssoftware die mit der
gleichnamigen Hardware kommt. Ist von 1993. Samplemanager
kommt dem nahe, arbeitet intern aber immer mit 16Bit. Von
daher kann ich damit nur einen halb so großen Sample laden.
Die Wiedergabe Qualität ist auch nicht die selbe.


1. Wenn Du Dich bei einer Audio-Bearbeitungs oder Abspiel Software nur auf's Chipram beschränkst, hast Du selbst bei einem AGA Amiga nur 2MB, was nicht gerade üppig ist...

2. Alle mir bekannten Audio-Bearbeitungsprogramme (selbst das uralte Originalprogramm zum Parallelportsampler "Stereomaster") können Samples auch aus dem Fastram abspielen bzw. welche dort hineinsamplen...

3. Für ganz große Samples (z.B. ganze Audio-Tracks von CD) benutzt man sowieso sogenanntes "Double Buffered Sampling", d.h. es wird während das Sample abgespielt wird, von Disk nachgeladen.

4. Um 16 Bit Samples (z.B. Audio CD Tracks) über Paula abzuspielen, nimm am besten "play16" aus dem Aminet.


--

http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

16.01.2006, 09:59 Uhr

MaikG
Posts: 5172
Nutzer
>> Es werden von dem Programm sachen ins FastRam geladen,
>> die ins Chipram müssen,

>Wie kommst Du darauf?

Die Wellenform wird, wenn Fastram verfügbar ist falsch(Eckig)
dargestellt wenn man sie vergrößert.


>1. Wenn Du Dich bei einer Audio-Bearbeitungs oder Abspiel
>Software nur auf's Chipram beschränkst, hast Du selbst
>bei einem AGA Amiga nur 2MB, was nicht gerade üppig ist...

Mit Megalo bearbeite ich schonmal 100 MB große Samples.


2. Alle mir bekannten Audio-Bearbeitungsprogramme (selbst das uralte
Originalprogramm zum Parallelportsampler "Stereomaster") können
Samples auch aus dem Fastram abspielen bzw. welche dort
hineinsamplen...

Kein Megalo ja auch...

[ - Antworten - Zitieren - Direktlink - ]

16.01.2006, 13:00 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von thomas:
Zitat:
Man kann also sagen wir mit Programm "Patch" in einem
Speicherbereich schreiben der aber von Programm "Megalosound"
allociert wurde?

Yep. Sonst würde das komplette Message-System des AmigaOS nicht funktionieren. Dabei werden nämlich nur Pointer weitergegeben, kein Speicher kopiert.
Nicht nur das. Libraries belegen Speicherbereiche im Kontext des Aufrufers, auch dann, wenn sie diese später im Kontext eines anderen Programms wiederverwenden.
Das gilt insb. wenn bestimmte Funktionen zum ersten Mal aufgerufen werden.
Vor allem aber: wenn man ein Programm mittels LoadSeg in den Speicher läd, läuft dieses noch gar nicht. Der Besitzer dieses Speichers ist somit derjenige, der das Laden veranlaßt hat.
Das neue Programm greift nach dem Starten also schon von vornherein auf Speicherbereiche zu, die es selber nicht belegt haben kann.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

16.01.2006, 13:21 Uhr

bubblebobble
Posts: 707
Nutzer
Von mir ist Samplemanager und HD-Rec.

Was ich nicht verstehe, du schreibst Samplemanager spielt in schlechterer Qualität ab. Wie kann das sein ?
Samplemanager gibt den Sound via AHI wieder, auf Paula mit dem 14bit Treiber. Dein Sample hat nur 8bit. Selbst wenn Megalosound irgendeine noch trickreichere Routine wie den 14bit AHI sound nutzen würde, hast du keinen besseren Klang. Evtl. liegt das am Amiga-LowpassFilter ?

Aber es geht ja auch ums Bearbeiten, ich denke nicht dass du das du das Sample nur zum Anhören reinladen willst. Samplemanager und HD-Rec bearbeiten die Samples immer in der gleichen, sehr guten Qualität, egal wie es über den Paula Chip klingt.

Samplemanager hat den Nachteil, dass er das Sample komplett in den RAM laden muss, und das in 16bit stereo. Dafür wird auch alles in 16bit bearbeitet, und erst beim Speichern wieder in 8bit gewandelt, was natürlich besser ist als in jedem Bearbeitungsschritt 8bit zu haben.

Noch besser wäre für dich HD-Rec, weil es hier so gut wie kein Limit gibt für die Soundfiles (ok, max. ca. 2h). HD-Rec bearbeitet Samples sogar in 32bit, und kann auch direkt als mp3 exportieren. HD-Rec hat auch eine etwas schönere Darstellung der Samples, und viel mehr DSP Effekte.

Was willst du denn mit dem Sample machen ?

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

16.01.2006, 18:54 Uhr

MaikG
Posts: 5172
Nutzer
>Vor allem aber: wenn man ein Programm mittels LoadSeg in
>den Speicher läd, läuft dieses noch gar nicht. Der Besitzer
>dieses Speichers ist somit derjenige, der das Laden veranlaßt
>hat.
>Das neue Programm greift nach dem Starten also schon von
>vornherein auf Speicherbereiche zu, die es selber nicht belegt
>haben kann.

Ich dachte mehr daran Megalosound zu starten, dann sucht
mein Programm im Speicher danach und ändert es. LoadSeg habe ich
noch nie benutzt.


>Von mir ist Samplemanager und HD-Rec.
>Was ich nicht verstehe, du schreibst Samplemanager
>spielt in schlechterer Qualität ab. Wie kann das sein ?

Spielt über AHI ab, hat mit Samplemanager an sich nichts
zu tun. Bei Amplifier und MakeCD stelle ich auch immer
auf direkte Paula ausgabe.
AHI läuft auf 8Bit Stereo 22050, der Lowpass Filter ist aus.

>Aber es geht ja auch ums Bearbeiten, ich denke nicht
>dass du das du das Sample nur zum Anhören reinladen
>willst.

Wie soll ich was bearbeiten wenn ich es nicht hören kann?

>Was willst du denn mit dem Sample machen ?

Meistens nur Schneiden/Faden Bias. Manchmal Effekte
wie Höhen,Tiefen, Echo, Pitch, Phaser etc.

Das meiste kann Samplemanager, nur die Länge der Samples
ist auf die hälfte beschränkt.


[ Dieser Beitrag wurde von MaikG am 16.01.2006 um 18:56 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

16.01.2006, 19:43 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von MaikG:
Ich dachte mehr daran Megalosound zu starten, dann sucht
mein Programm im Speicher danach und ändert es. LoadSeg habe ich
noch nie benutzt.


Direkt vielleicht nicht, aber wenn ein Programm ein anderes aufruft, muß dieses natürlich immer erst geladen werden, bevor es gestartet wird ;)
Wenn das Programm komprimiert oder verschlüsselt ist, mußt Du es natürlich erst starten, bevor Du es patchen kannst, nur eine geeignete Methoden zum Anhalten, bzw. patchen zum richtigen Zeitpunkt, mußt Du dann noch finden.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

16.01.2006, 23:41 Uhr

MaikG
Posts: 5172
Nutzer
>Direkt vielleicht nicht, aber wenn ein Programm ein
>anderes aufruft, muß dieses natürlich immer erst geladen
>werden, bevor es gestartet wird ;)

Ich dachte an folgendes Script:
run >NIL: Megalosound
Patch


>Wenn das Programm komprimiert oder verschlüsselt ist,
>mußt Du es natürlich erst starten, bevor Du es patchen
>kannst, nur eine geeignete Methoden zum Anhalten, bzw.
>patchen zum richtigen Zeitpunkt, mußt Du dann noch finden.

Anhalten? Zum richtigen Zeitpunkt? Das wird doch on the fly
gehen.


[ - Antworten - Zitieren - Direktlink - ]

17.01.2006, 13:18 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von MaikG:
Ich dachte an folgendes Script:
run >NIL: Megalosound
Patch

Geht mit Sicherheit auch, zumindest mit dem aktuellen AmigaOS. Aber das Starten von Megalosound kann das Patchprogramm doch locker mit erledigen.
Das hat den Vorteil, das es die Adresse des Tasks und den Speicherbereich der Ausgangsdaten schon mal kennt.
Zitat:
Anhalten? Zum richtigen Zeitpunkt? Das wird doch on the fly
gehen.

Das hängt natürlich davon ab, was das Programm macht. Wenn es nach dem Start auf User-Input wartet, ist es ja angehalten.
Nur wenn die Funktionen, die Du patchen willst, schon vorher aufgerufen werden, dann wird es für Dich schwieriger...

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]


-1- 2 [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Datei Decodieren [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.