Neuorientierung von eMule
#81
Posted 04 February 2004 - 01:30 PM
Ich habe ein Konzept aufgestellt, dass außer eines gravierenden Problems, mir schlüssig erscheint. Es steht jedem frei Verbesserungen oder Fehler zu posten.
CU
Mr Faber
#82
Posted 04 February 2004 - 02:42 PM
Tantal, on Nov 21 2003, 07:36 AM, said:
Für Leute ohne absolutes Gehör sind MP3's spätestens ab einer Bitrate von 192 kBit/s nicht vom Original zu unterscheiden. Das dürfte auf die meisten Menschen zutreffen. Diejenigen, deren Gehör nicht in das psychoakustische Modell passt, sind da halt arm dran. Allerdings finde ich dass auch viel nur psychisch bedingt ist: Ich kenen Leute die ernsthaft behaupten, eine kopierte Audio-CD würde anders klingen als das Original. Das ist dann einfach lachhaft.
Man kann durchaus auch mit sehr niedrigen Datenraten und MPEG-2 gute Ergebnisse erzielen, [...].
Qualität ist mit fast jedem Codec möglich, steht und fällt aber mit der Erfahrung des Benutzers.
Sorry, so nicht ganz richtig.
Bin in Elektroakustik recht bewandert.
Auf einer recht einfachen Kompakt-Anlage wird man kaum einen Unterschiedt zwischen MP3 bzw. einer kopierten CD und der Orginal CD hören.
Bei besserem bis sehr gutem Equipment sieht die Sache schon ein wenig anders aus, und zwar wie folgt:
MP3: Bei MP3 handelt es sich um eine Datenreduktion, musikalische Informationen werden zwecks Datenkompression fallen gelassen, somit geht auch immer ein Verlust an musikalischer Information erhein. Ergo muß MP3 in den meisten fällen "anders" klingen als das Orginal.
Kopierte CD: Da kopierte CDs nicht die Pitch-Tiefe und -Schärfe wie eine Orginal-CD aufweisen, kann dies zu einem sogenannten Zeitversatz führen. Dies bedeutet das die Abspieleinheit bei der Umwandlung digitaler in analoger Daten ein paar Nano-Sekunden Verzug hat. Dies ist in den meisten Fällen unbedeutend bis nicht wahrnehmbar. Über sehr guten Abhörgeräten und bei sehr anspruchsvollem Material kann dies aber schon auffallen.
Dies gilt leider nicht für die meisten Mainstream-Alben, diese sind ab Werk meist schon so dynamisch so verkrüppelt das hier eine Kompression oder gar eine 1:1 Kopie garkeine negativen Auswirkungen hat.
#83
Posted 04 February 2004 - 04:24 PM
Mußt Du mal gucken...
Horde ist Handeln,
eMule ist Sharen.
50% vom Upload auf eine Datei, GENAU EINE Datei, KONSTANT zu legen... Also... Öhm.... da mußt Du nochmal genauer drüber nachdenken...
Die Folge wird sein, dass sobald das File runtergezogen ist, eMule beendet wird. Desweitern verkürzt sich die "VorHaltezeit" von diesem "Horde-"File extrem im Netz...
Und dieses ganze "QueueOverflow with Minimumcontingent + SUQWT", das kannste Dir meiner unmaßgeblichen Meinung nach komplett an die Backe schmieren, wenn (!) Du bereits 50% vom Upload weggegeben hast, dann ist das komplett Banane.

Ich share hier 6 Serien, ca. 300 Files... und wenn Du da 50% Upload wegnimmst... Na, dann schauen die User aber sehr sparsam.... selbst mit n-way queue komm ich gerade 2x in 24h durch...
Ganz das Gegenteil von Horde müßte es sein... der Mainstream müsste gebremmst und die Rares geboosted werden
Quote
stückchenschieben
else
Full chunk schieben
... aber auf mich hört ja keiner...
#84
Posted 04 February 2004 - 07:22 PM
#85
Posted 05 February 2004 - 11:30 PM
aber na ja, Horde ist nicht sharen, ich glaube das ist hier deutlich geworden.
Ich brauche bei manchen Files Locker 12 Stunden bis ich das erste Byte
zu sehen bekomme. Und das gerade da, wo es kein Mainstream ist.
Stelle ich mir jetzt noch vor, da wo ich mich gerade einklinken will, spielt
eine wilde Horde, vieleicht sogar noch mit Queue-Ranking-Save. Bitte... wann soll
ich, oder irgend jemand anderes noch mitspielen?
@Faber:
Horde ist nichts weiter, als ein Versuch, Marktanteile zum Donkey zurück zuholen.
Es funktioniert genauso wie ein Communitystring. Sich bei allen anstellen und saugen
und einen großen Teil unter seinen Freunden zu verteilen. Ich habe so
etwas neulich im Mainstream beobacht können: Super Verteilung unter Emules.
Jeder hat etwas, aber nie das gleiche. Nur 8 Hybriben sehen fast identisch aus und haben
bei mir natürlich bis zum Schuß nicht upgelodet. Wenn es da nicht klingelt.
Wenn sich die Devs hier nicht geäußert haben, man spricht inzwischen von 2 Mil.
Teilnehmern am Edonkey-Netzwerk, ca 95% sind Emule und alle 4 Wochen kommt
das gleiche Thema wieder hoch, ich kann sie verstehen.
Noch etwas:
Emule bietet genügend Steuerungmöglichkeiten, Autouploadprio, Autodownloadprio
Friendupload, Manuelles Quellenverschieben etc. Und nur weil Edonkey eine unfaire
Methode beherrscht, muß dieses doch nicht im Emule übernommen werden.
Kleinere Chunks, gute Idee, aber wenn dann für alle und zum sharen und nicht zum traden.
Sei nicht böse, wenn Deine Idee hier nicht ganz so viele Anhänger findet.
Mika
#86
Posted 06 February 2004 - 01:51 PM
Es geht nicht um das eDonkey Horde. Die Implementation ist nicht gut, aber immer noch besser als die vom Creditsystem in eMule. Ladet mal eine seltene Datei, die sowohl von eMule als auch von eDonkey geshared wird, herunter. Man fängt eigentlich immer nach nur kurzer Zeit vom eDonkey an zu downloaden, da es eine QueuePerFile hat und man so direkt zum Download kommt. Also ist Horde bzw. eDonkey nicht der Killer von seltene Dateien sondern effektiver für diese als eMule.
Lest euch erst mal meine Implementation durch, die weicht nämlich teilweise sehr von der vom eDonkey ab. Zweitens kann man Horde im Client ausschalten, also haben Releaser keine Nachteile.
Wenn Ihr meine Posts durchlesen und euch mit der Problematik auseinandersetzen würdet, müsstet Ihr einsehen, dass eher das Creditsystem der Dateivielfalt schadet. Man kann es nämlich sehr einfach mit sehr großem Erfolg für den eigenen Download, aber mit großem Schaden für die Dateivielfalt und und alle anderen Clients ausnutzen. Ich glaube es steht hier nicht zur Debatte, dass das viele machen würden, wenn sie wüssten wie. Und man muss weiß Gott kein Genie sein um das rauszubekommen.
CU
Mr Faber
This post has been edited by Mr Faber: 06 February 2004 - 03:46 PM
#87
Posted 06 February 2004 - 04:07 PM
Warum denn überhaupt denn Stress machen, und ein "Horde" implementieren??
Am besten fährt man doch, wenn man ab und an zu Overnet switcht. Vor allem bei weniger verbreiteten Files.
#88
Posted 06 February 2004 - 04:25 PM
cyhyryiys, on Feb 6 2004, 04:07 PM, said:
Genau so habe ich mir das auch gedacht. Metamachine hat gute Ideen, nur setzen sie diese leider nicht effektiv um. Dazu gibt es ja den OpenSource eMule Client
Rate mal warum nicht Overnet-Kademlia in eMule sondern ein eigenes Kademlia-System integriert wurde?
CU
Mr Faber
This post has been edited by Mr Faber: 06 February 2004 - 04:26 PM
#89
Posted 07 February 2004 - 12:43 AM
Mr Faber, on Feb 6 2004, 05:25 PM, said:
CU
Mr Faber
... weil die Nasen von Overnet / eDonkey "vielleicht" nicht den Source rausgerückt haben und weil die Nasen von Overnet / eDonkey "nicht" kooperiert haben, sondern kommerziell orientiert sind?
Du meine Güte, wenn J. etwas gegen die Bots hätte unternehmen wollen, dann hätte er es LANGE BEVOR eMule unternehmen KÖNNEN. eMule war die Antwort auf die Bots. NIEMALS URSACHE UND WIRKUNG VERWECHSELN!
Immer das dumme Gelaber, von Nasen, die keine Ahung haben...

Mein Gott, Du mußt sie wirklich lieben...
This post has been edited by Tron: 07 February 2004 - 12:48 AM
#90
Posted 07 February 2004 - 09:05 AM
Unknown1 hat diesen Schritt, soweit ich weiß, mal damit begründet, dass erstens keine Kooperationsbereitschaft seitens Metamachine existiere, zweitens immer alle das Netz betreffenden Änderungen abgesprochen werden müssten und drittens einige Implementationen besser gelöst werden könnten.
Closed Source sollte kein Problem sein, wie man unschwer am mlDonkey-Clienten erkennen kann. Die Entwickler von diesem haben nämlich den Overnet-Algorithmus integriert. Auch war eDonkey nie Open Source und trotzdem gibt es eMule. Macht es Klick?
CU
Mr Faber
This post has been edited by Mr Faber: 07 February 2004 - 09:08 AM
#91
Posted 07 February 2004 - 10:45 AM
#92
Posted 07 February 2004 - 10:51 AM
Das nun ein Client nicht open source ist und sich Leute darüber aufregen lässt mir immer wieder ein lächeln über die Backen huschen.
Der Mensch konsumiert ja sonst immer nur bewusst:
Man trinkt auch immer nur die Aldi-Cola statt Coke und holt sich seine Fritten niemals in Mc Donalds, nicht? Denn bei den anderen stehen ja haarklein die Inhaltstoffe drauf, was bei Coke und Mc nicht immer der Fall ist
Quote
Mldonkey sendet übrigens nix ausser Datenschrott an ON und er erhält auch nix ausser corruptions. Soviel zur Implementation
#93
Posted 07 February 2004 - 07:12 PM
Tron, on Feb 7 2004, 12:43 AM, said:
Diese "Nasen" planen ein Netzwerk mit Plug-Ins, das den Esel um Gnutella, Bittorrent usw. erweitern soll und haben dafür auch ein SDK veröffentlicht.
Allerdings wollen sie diese nicht selbst entwickeln.
Bei einem kommerziellen Projekt ist so ein Vorgehen, meiner Meinung nach, zum Scheitern verurteilt.
Wer arbeitet schon gerne kostenlos für das Geld anderer.
Aber was mich sehr verwundert, ist, daß viele gute Ideen von Jed beim Emule-Team einfach nicht aufgenommen werden.
Nicht alles, was er plant (oder überlegt und entwickelt hat) ist schlecht
#94
Posted 08 February 2004 - 03:45 PM
Quote
posted by Anonymous on February 06, 2004 @ 02:02pm
read the full story here:
http://forums.sharea...&threadid=14533
not a reason to implement MUTE instead of kademlia?
#95
Posted 09 February 2004 - 07:26 PM
Magnet Uri, on Feb 8 2004, 03:45 PM, said:
Quote
posted by Anonymous on February 06, 2004 @ 02:02pm
read the full story here:
http://forums.sharea...&threadid=14533
not a reason to implement MUTE instead of kademlia?
what about kdrive?
It can connect to ON, but or now it is in an early developement phase
#96
Posted 09 February 2004 - 07:31 PM
[ ~ Epaminondas ~ ]
Es gibt keine dummen Fragen - nur dumme Antworten. Aber die geben wir gerne!
----------------------------
Minister of Permanent Outgoing Incomes in the New World Order.
Botschafter für diplomatische Zusammenarbeit von Weltordnungen der UWO.
#97
Posted 11 February 2004 - 06:57 PM
Epaminondas, on Feb 9 2004, 07:31 PM, said:
oh, ist ja dt. forenbereich
#98
Posted 19 February 2004 - 04:43 PM
cyhyryiys, on Feb 9 2004, 07:26 PM, said:
,Feb 8 2004, on 03:45 PM, said:
Quote
posted by Anonymous on February 06, 2004 @ 02:02pm
read the full story here:
http://forums.sharea...&threadid=14533
not a reason to implement MUTE instead of kademlia?
what about kdrive?
It can connect to ON, but or now it is in an early developement phase
kdrive is quit good, but brings a lot of danger to public sharing, read the link beneath. Emule needs not kademila, but a waste mute style hybrid.
Quote
Subject: Re: Partials in private circles (re: was: Open Letter to MM: Kdrive partials)
http://groups.yahoo....ION/message/639
Quote
you are a pioneer, you know, and that´s why there has to be set a golden rule
with establishing kdrive (which is as well a rule for gnutella, if there are
private networks).
If all people in the future only share in private circles (password or public
acess) filesharing will die in the public.
so there has to be a golden rule, which you should declare as well on your
homepage.
Every media, downloaded from a acessable or not acessable kdrive, MUST be
available for the public overnet share in the incoming folder.
More: Even the partials in the temp folder have to be acessable on overnet, the
public p2p.
Otherwise filesharing will die.
This golden rule has to beaccept as well for business k-circles, this means if
you have a private folder or chatroom, even then the partials from downloaded
things should be available for the public.
So private sharing is ok, but no exclusive sharing please.
PARTIALS ON PRIVATE NETWORKS MUST BE FREE FOR THE PUBLIC IF THE APP IS HYBRID
WITH A PUBLIC P2P APP ! (as well for a queryhitback on keywordsearches).
thanks
http://www.zeropaid....o/02152004d.php
http://www.kdrive.com/










Sign In
Register


