Nemp 5.1

Gausi · Verfasst: Sa 10.05.08 21:12

Wo das Thema wieder oben ist...

@Martok: Das ist mir auch schon ein- oder zweimal passiert und ist in der Tat sehr ärgerlich. Ich schau mal, was man da machen kann.

@Yogu: Das ist ein sehr spezieller Wunsch. Muss ich mir mal drüber Gedanken machen, wie man das hinkriegt, dass es halbwegs universell einsetzbar ist. Nemp sucht die Cover übrigens im Ordner der mp3, in einem Unterordner, der ein "Cover" enthält, im übergeordneten Ordner (Wenn da nicht zu viel Zeug drin ist), und in einem "Schwesterordner" mit "Cover" drin, wenn im "Parent-Ordner" nicht zuviel Zeug drin ist. Das Cover, was dann gefunden wird, wird gehasht, die ID gespeichert und ein Bitmap auf 250x250 gestaucht mit der ID als Namen unter \Anwendungsdaten\<user>\Nemp\... bzw. im Programmordner erstellt, das dann für den Coverflow verwendet wird.

Ich möchte erst noch eine kleine OpenSource-Unit fertigmachen, die sich aus meiner Diplomarbeit ergeben hat, dann mach ich hier wieder weiter.

Und schon wieder orange...hier gehts ja los, meine Güte...

Für "Alles in einem Ordner" ist Nemp nicht konzipiert. Nemp ist für "Alben-basierte-Sammlungen" erdacht. Wenn alle Dateien in einem Ordner sind, dann wäre es evtl. besser, die Cover im ID3-Tag zu speichern. Das geht mit Nemp über Details->Erweiterte ID3v2-Frames

_________________
We are, we were and will not be.

Yogu · Verfasst: Sa 10.05.08 21:27

Hallo,

ich würde einfach beim Coversuchen in den Ordern suchen, die angegeben wurden, und wenn mehrere Dateien vorhanden sind, mit den Tags vergleichen. Oder machst du das schon? Wenn ja, ist irgendetwas falsch gelaufen. So wie es sich anhört, müsste es dann eigentlich klappen. Der Cover-Ordner ist ja ein Nebenordner vom Bibilitheksordner, und ich habe ihn in den Einstellungen eingegeben. Dort drin sind nur eben ein paar zu viele, also muss entschieden werden. Und das eben per ID3-Tag, oder?

Aber ich kann natürlich auch die Tags für Covers nehmen. Ist wahrscheinlich eh besser, dann kann ich ganz einfach Musik woanders hin kopieren. Zuerst dachte ich, das gleiche Cover 10 mal speichern wäre sinnlos, aber die sind ja verhältnismäßig wirklich klein.

Grüße,
Yogu

Gausi · Verfasst: Sa 10.05.08 21:47

Nein, wenn Bilder gefunden werden, wird angenommen, dass dort nur Bilder eines Albums zu finden sind. Und dann wird das genommen, was wahrscheinlich das Front-Cover ist, d.h. es ist z.B. ein "front" drin.

Wie gesagt:

Für einzelne Dateien: Bilder besser in die Tags.

Für komplette Alben: Einen eigenen Ordner anlegen und die Bilder da reinpacken.

_________________
We are, we were and will not be.

jakobwenzel · Verfasst: So 11.05.08 10:50

Was ich noch gut fände, wäre, wenn im Tag gespeicherte Cover gegenüber "irgendwo" gefundenen bevorzugt werden würden.
So kommt bei mir in vielen Fällen nur Schwachsinn, und um das ganze manuell anzupassen sinds mir eindeutig zu viele.

_________________
I thought what I'd do was, I'd pretend I was one of those deaf-mutes.

Yogu · Verfasst: Mo 12.05.08 21:07

Hallo,

das Problem hatte ich auch. Ich habe es dadurch gelöst, dass ich Covers nicht mehr von der Festplatte laden lasse. Das geht bei mir, weil ich alle in den Tags speichere. Aber das muss natürlich nicht bei allen sein. Auf jeden Fall fände ich es gut, wenn man Covers löschen könnte. Oder sollte das eigentlich gehen, wenn man so eine Vorschau aus dem Cover-Ordner löscht? Bei mir hat das nicht so richtig geklappt.

Grüße,
Yogu

Gausi · Verfasst: Mo 12.05.08 22:38

Ich meine eigentlich, dass das so wäre, das Tag-Cover bevorzugt würden :gruebel:

Muss ich mal nachgucken.

Wahrscheinlich kommt innerhalb des nächsten Monats ein Bugfix-Neue-Bass.dll-Update raus, bevor ich mich an ein paar kompliziertere Dinge ran mache, die ein paar mehr Änderungen brauchen.

_________________
We are, we were and will not be.

Gausi · Verfasst: Di 20.05.08 21:58

Ich habe gerade etwas rumgespielt, um diesem Bug auf die Schliche zu kommen. Ich hab ihn gefunden und hoffentlich lokal ausgemerzt.

Man kann ihn übrigens viel leichter reproduzieren. Einfach einen Titel, der in der Liste nach dem gerade abgespielten Eintrag kommt, auf eine beliebige Position darüber schieben und dann in der Medienbib einen Titel "als nächstes abspielen". Da kommt die Playlist schon ins Stolpern, und fällt irgendwann ein paar Aktionen später voll auf die Schnauze.

Also: Das bis zum nächsten (kleinen) Update (wahrscheinlich innerhalb der nächsten Woche) sein lassen. ;-)

Edit(22.Mai): So, das ging schneller. Nochmal schieben mag ich aber nicht. ;-)

_________________
We are, we were and will not be.

Martok · Verfasst: Mo 02.06.08 03:06

Hm, doof.

Hab nun heute dein (klammheimlich gemachtes) Update 3.0.2 drin. Seitdem gehen ein paar Sachen nicht mehr...

:arrow:

Unter gewissen Umständen schmeißt der beim Trackwechsel eine EListError. Welche das sind weiß ich nicht, ich merke es nur immer, wenn dann auf einmal Musik aus ist. Manuell reproduzieren klappt so nicht, beim automatischen Titelwechsel passiert das aber recht häufig.
:arrow:

die Playlist zeigt nur noch selten Hints an
:arrow:

ob der Bug jetzt noch da ist weiß ich nicht, aber in 3.0.1 war ers: Manchmal kommt der 'Zeiger' in Cuesheets nicht mit. Der bleibt dann auf einem Eintrag hängen und lässt sich von der wirklichen Zeit nicht beeinflussen

Einmal per Playlist-Doppelklick eine andere Position anspringen hilft hier.

Tja, ich geh dann mal Downgraden...

PS: in der Aboutbox steht im Deutschen "fühlen Sie sich frei, mir eine Postkarte zu senden". Wüsste nicht das jemand "feel free to" schonmal so übersetzt hat

_________________
"The phoenix's price isn't inevitable. It's not part of some deep balance built into the universe. It's just the parts of the game where you haven't figured out yet how to cheat."

Gausi · Verfasst: Mo 02.06.08 08:41

Hm. Das sind alles Sachen, die ich hier keineswegs beobachten kann. Am Titelwechsel habe ich eigentlich nichts verändert und die Playlist läuft stundenlang ohne Probleme durch. Auch die Hints kommen bei mir wie gewohnt. Das "feel free" ist in 3.0.2 übrigens anders übersetzt - theoretisch sollte man den "locale" -Ordner der neuen Version in der alten benutzen können.

Hast du denn bei dem Update alle Addons zur bass.dll durch die neue Version ersetzt? Das würde mir jetzt als mögliche Fehlerquelle einfallen. :nixweiss:

Edit: eine falsche bass.dll-Addon-Version gibt beim Start eine Fehlermeldung, mit der falschen bass.dll läuft es gar nicht. Daran kanns also nicht liegen. Fehlende Hints konnte ich gerade in 3.0.2 und 3.0.1 reproduzieren, wenn die Titel sehr kurz sind. Scheint an der Positionsänderung der Anzeige zu liegen, dass der VST die Hints dann nicht auslöst. Klickt man auf Pause, werden sie wieder angezeigt.

_________________
We are, we were and will not be.

matze · Verfasst: Mo 02.06.08 10:40

Kann NEMP eigentlich mit CUE Dateien umgehen?

_________________
In the beginning was the word.
And the word was content-type: text/plain.

Gausi · Verfasst: Mo 02.06.08 10:46

Ja, auch wenn das laut Martok nicht immer funktioniert. Und ich sehe grade, dass das über die Dialoge nicht bereitgestellt wird. :oops:

Aber: Cue per Drag&Drop geht, und wenn es zu einer "abcd.mp3" eine "abcd.cue" gibt, wird die automatisch geladen.

Edit: Irgendwas hab ich beim Updaten auf die neue Bass-Version mit den Cues verkehrt gemacht(*). Da läuft jetzt tatsächlich einiges nicht so, wie es soll. Muss ich nochmal drübergucken. Ich hoffe, ich komme dann nicht durcheinander, weil ich schon an 3.1 arbeite. :oops:

___________
(*): Das war nötig, weil sich in der Bass u.A. das Sync-System etwas geändert hat

_________________
We are, we were and will not be.

matze · Verfasst: Mo 02.06.08 10:50

cool. Danke !

_________________
In the beginning was the word.
And the word was content-type: text/plain.

Gausi · Verfasst: Mo 02.06.08 12:35

Ok. erzählen wir mal eine Geschichte aus der Reihe

Die dümmsten Programmierfehler der Welt

Schauen wir uns den alten Code mal an

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:

      // altes Sync-Handle entfernen
      BASS_ChannelRemoveSync(mainstream, fCueSyncHandle);
      // neues setzen
      if MainAudioFile.CueList.Count-1 > NewCueIdx then
          fCueSyncHandle := Bass_ChannelSetSync(Mainstream,
                BASS_SYNC_POS or BASS_SYNC_MESSAGE,
                Bass_ChannelSeconds2Bytes(mainstream,(TPlaylistFile(MainAudioFile.CueList[NewCueIdx+1])).Index01),
                Syncproc(WM_NextCue),
                0);

Jetzt hat sich in der bass.dll etwas geändert. Die Paramter müssen jetzt etwas anders aussehen. Also schreiben wir den Code etwas um:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:

      // altes Sync-Handle entfernen
      BASS_ChannelRemoveSync(mainstream, fCueSyncHandle);
      // neues setzen
      if MainAudioFile.CueList.Count-1 > NewCueIdx then ;
          fCueSyncHandle := Bass_ChannelSetSync(Mainstream,
                BASS_SYNC_POS,
                Bass_ChannelSeconds2Bytes(mainstream,(TPlaylistFile(MainAudioFile.CueList[NewCueIdx+1])).Index01),
                @NextCueProc,
                Self);

Und jetzt die Preisfrage: Wer findet den Fehler, der dafür verantwortlich ist, dass in der neuen Version ab und zu ein Listen-Fehler kommt? Na? :think:

Die korrigierte Fassung kommt in den nächsten Tagen. Der aktuelle Code ist schon was weiter, und das Backup rauskramen, neu kompilieren und zusammenpacken möchte ich nicht auf die Schnelle machen.

_________________
We are, we were and will not be.

alias5000 · Verfasst: Mo 02.06.08 12:46

hehe, ohje Gausi, das ist ein hinterhältiger Fehler :autsch:

_________________
Programmers never die, they just GOSUB without RETURN

Martok · Verfasst: Di 03.06.08 13:10

Naja, und die Medienbib verhält sich nach wie vor seltsam...

Ist ein Laufwerk nicht da, wird immer noch auf irgend was anderes korrigiert wo es einen gleichnamigen Ordner gibt. Ob da die Dateien sind, wird überhaupt nicht geprüft. Und natürlich wird das dann auch völlig falsch gespeichert... Hier sollte man sicherlich nicht präsente Dateien ausblenden (weiß nicht wie du das im Moment machst, da ich wegen dem Fehler immer alles korrigiert kriege

)

Und die Suche hat noch einen entscheidenden Nachteil: man kann nicht auf ein Verzeichnis begrenzen. Fällt grade bei der Schnellsuche auf: ich habe 'Browsen nach Verzeichnis' an. Damit wähle ich mir einen Ordner aus, der wird dann angezeigt. Wenn ich jetzt was in der Schnellsuche suche (wasn Satz^^), dann sucht er wieder überall... Wozu kann man dann überhaupt einen Ordner auswählen? :gruebel:

_________________
"The phoenix's price isn't inevitable. It's not part of some deep balance built into the universe. It's just the parts of the game where you haven't figured out yet how to cheat."

Gausi · Verfasst: Di 03.06.08 13:40

Das Lade-Verhalten der Medienbib wird überarbeitet werden. Das wird aber wohl etwas aufwändiger, daher ist das in der Version, die hauptsächlich nur den wirklich fiesen Playlist-Bug beheben sollte (dafür hab ich aber ja nen anderen eingebaut :tongue:

), noch nicht mit drin. Nicht vorhandene Dateien ausblenden möchte ich nicht - bei mir ist es z.B. oft so, dass ich den Player starte, und danach erst die externe Platte anmache. Ich werde da wohl etwas mit Laufwerks-ID zusammenbasteln und anhand dessen die Pfade beim Laden zusammensetzen.

Schnellsuche vs. Vorauswahl: Das finde ich so, wie es ist, sinnvoll. Die Vorauswahl kann man zum Stöbern benutzen, bis man was gefunden hat, was man jetzt hören will. Die Suche ist für die Suche nach einem speziellen Titel oder Artist da. Fällt einem beim Browsen ein spezieller Titel ein, kann man direkt danach suchen, ohne wieder zur Wurzel zu gehen. Eine Suche in einem Verzeichnis selbst halte ich für relativ selten sinnvoll - zu Not kann man nach "<\verzeichnis\>(Leerzeichen)<suchbegriff>" suchen. ;-)

Die Schnellsuche wird auch überarbeitet werden und (hoffentlich) deutlich schneller werden. Das dauert aber auch etwas länger.

_________________
We are, we were and will not be.

Martok · Verfasst: Di 03.06.08 14:22

Gausi hat folgendes geschrieben:

Nicht vorhandene Dateien ausblenden möchte ich nicht - bei mir ist es z.B. oft so, dass ich den Player starte, und danach erst die externe Platte anmache.

Ist n Argument. Ok, lass es so

Gausi hat folgendes geschrieben:

Ich werde da wohl etwas mit Laufwerks-ID zusammenbasteln und anhand dessen die Pfade beim Laden zusammensetzen.

Egal wie, Hauptsache anders als jetzt

Gausi hat folgendes geschrieben:

Eine Suche in einem Verzeichnis selbst halte ich für relativ selten sinnvoll -

Hm... also ich organisiere ja meine Musik in Verzeichnissen...
Situation: Verzeichnis, dass wieder in Ordnern mehrere Compilations enthält. Jetzt will ich wissen, welche Lieder von einem Künstler da drin sind. Schnellsuche liefert mir aber auch die Treffer in den Einzel-Alben und ich darf dann in der 'Pfad'-Spalte suchen, obwohl ich schonmal vorgefiltert hatte.

Gausi hat folgendes geschrieben:

Fällt einem beim Browsen ein spezieller Titel ein, kann man direkt danach suchen, ohne wieder zur Wurzel zu gehen.

Ähm, naja. Das halte ich für vertretbar verglichen mit dem oben genannten.

Gausi hat folgendes geschrieben:

zu Not kann man nach "<\verzeichnis\>(Leerzeichen)<suchbegriff>" suchen. ;-)

.

Nicht dein Ernst :shock:

_________________
"The phoenix's price isn't inevitable. It's not part of some deep balance built into the universe. It's just the parts of the game where you haven't figured out yet how to cheat."

ZeitGeist87 · Verfasst: Di 03.06.08 14:23

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:

      // altes Sync-Handle entfernen
      BASS_ChannelRemoveSync(mainstream, fCueSyncHandle);
      // neues setzen
      if MainAudioFile.CueList.Count-1 > NewCueIdx then ; //der da? ;-)
          fCueSyncHandle := Bass_ChannelSetSync(Mainstream,
                BASS_SYNC_POS,
                Bass_ChannelSeconds2Bytes(mainstream,(TPlaylistFile(MainAudioFile.CueList[NewCueIdx+1])).Index01),
                @NextCueProc,
                Self);

_________________
Wer Provokationen, Ironie, Sarkasmus oder Zynismus herauslesen kann soll sie ignorieren um den Inhalt meiner Beiträge ungetrübt erfassen zu können.

Gausi · Verfasst: Di 03.06.08 14:53

@Zeitgeist: Der Kandidat erhält 100 Gummipunkte :tongue:

@Martok: Hm. Einen gewissen Sinn erkenne ich da schon. Problem ist aber unter anderem folgendes: Intuitiv wäre das ganze nur dann, wenn die Schnellsuche dann immer nur in den unten aufgelisteten Titeln sucht. Sonst wäre das Verhalten unddurchschaubar, wenn man z.B. mit der "großen Suche" was gesucht hat, und dann bei der Schnellsuche Titel von ganz woanders kommen, weil das zuletzt ausgesuchte Verzeichnis c:\Musik war. Dann aber wird die Bedienung unschön, wenn man nach einer Schnellsuche wieder was anderes schnell suchen will.

Eine Checkbox für "globale Schnellsuche" fände ich auch unschön - die müsste man dann immer wieder umchecken. Wäre die Lösung "Enter -> Globale Schnellsuche" , "Shift+Enter -> lokale Schnellsuche" ok? Das wäre dann zwar ein recht verstecktes Feature, würde mir persönlich aber sehr gefallen. ;-)

@Ernst: Eigentlich schon. Das mach ich auch öfter, wenn ich nach einem speziellen Verzeichnis suche. ;-)

_________________
We are, we were and will not be.

Martok · Verfasst: Di 03.06.08 15:26

Hm joa... gefällt mir. Aber lokal inwiefern? Lokal in der grade angezeigten Liste oder lokal in dem Verzeichnis?

Und @Ernst: bringt mir nix, da ich fast immer eine Datei suche und schon so ungefähr weiß wo sie ist

_________________
"The phoenix's price isn't inevitable. It's not part of some deep balance built into the universe. It's just the parts of the game where you haven't figured out yet how to cheat."

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme