Hey Johan,

I just tried this, but nothing ...

I noticed that you must be talking about the 24/96KHz version, that is, looking at the track times (look below, the first 9 tracks are the normal version, the second are the 24/96KHz version). There is a difference though ...
My picture of the 24/96Khz is "Morphed" and yours is not. My normal version is not either. This may tell nothing, but how good/official is your 96KHz version (ripped) ?

I saw that you play at -6dB which I did the same (as well as Q1 = 4).
I tried Attended Mode ...
(in an earlier XX version I played the album Unattendedly without problems)

Gerard, Mike,

Did anything change since 0.9u-v2 ? I tried to apply some changes which might help in that version, but didn't hear back from you.
If things are still the same, or changed (and still errors) I'd like to know, so I may be able to apply something else with the upcoming release.

Thanks,
Peter

A small update :

This problem is solved, but currently I can't upload a new version because of (rather major) other difficulties which must be solved first (I started something which is half-way now).

Btw, the problem occurs only when the Library Area is loaded with data from Galeries.
It is unrelated to being out of memory, and is merely a flaw of the OS just saying it is, while it is really about loading a picture from a file which doesn't hold a picture at all (and this by itself is a flaw of me ).

Hi Johan,

Of course everybody who wants something like this is right. However, so far I want to avoid this because it will influence sound (or maybe I should say : it most probably will and I *really* want to avoid SQ influences as long as I can, since I think currently SQ is the best). But I can also say this :

Although the "crash" like this doesn't look nice, it would really come down to something which works out exactly the same : stop Engine#3.

Please hold on to when I applied the "smart cutting" as I mentioned; at that moment the problem of "crashing" won't be there either. Ok ?

So it looks like you can copy this behaviour, right ?

Which track was it at ? I have that album too, so I can check it.

Nah, not.

Yet.

The top should show Artist and Album Name. This is derived from the folder structure and the "intelligence" needed for that depends on the naming you applied. This is unrelated to the data being held in the cue file because not everybody works with cue files ...

That you like to have the track number shown is nothing more than logic for someone who doesn't apply the track number in the name of the track. Psychologically for you this goes extra wrong because you have the track numbers in the cue data.
Anyway, here too, some intelligence can be applied to work out the track number (this is easy) and show it when not already there in the track name (a tad more difficult because how the track number is formatted (and where) is up to "you" again, and it has to anticipate on all the variations possible).
But I will dig up some brains and try (I know, for cue files this is a piece of cake, but still it can be so that cue file tracks contain the track numer already, and you don't want to have them shown twice).

What I indirectly meant is :

When you have named all your coverart as folder.jpg and you have put that in the directory as intended (by me, which is or in the directory where the music data is, or for a multi volume album in the directory that holds the album itself (with underneath the volumes) ...

a. you would see as much coverart as before (XX didn't dig up more);
b. it shouldn't produce those errors since they can only come from files which are not called folder.jpg while a folder.jpg is not in the directory(s) as mentioned;
c. yes it will be a bit slower in any case.

Ad c.
Which is most profound with a single core processor I now realize.
Btw this is related to the better rendering of the pictures (they are more beautiful) for which I can make a parameter to shut it off.

Ad a.
When you have the folder.jpg somewhere else (e.g. in a directory named "folder") or you often don't have a folder.jpg but e.g. a cover.jpg, it will be more slow because of that which may be *much* slower when you have a couple of other jpg's (like inlet1.jpg, back.jpg etc.) because they all have to be examined. Also, when these additional files are large (which could be the case with a high resolution scan for the booklet (to keep it readable)) it will be significantly more slow. Keep in mind though that this is caused then by no folder.jpg being present at the appointed place(s) (see above).

The errors, of course, should be solved. So I will look into that anyway.

Johan,

Do you now have more coverart showing up opposed to before ?
or
Do you have the feeling that many are different now ?

and

Most of your coverart for the cover will be named folder.jpg. But for the remainder, what name would you use for the one and only cover ?

The aCTC religion now has determined that even the artist name has disappeared on the coverart. So or not, if the CTCaCTC could vote for the artist name to be there, PeterSt would be forced to get it in. Mind you, this is disregarding the queue of aCTC priests, so, much is asked from the CTC community this time. If the gavel holder would be so kind to hand out a positive advise on this towards the members, we can get done with this quickly.

The anti-CTC formed a derival and is today celebrating its 5th day anniversary. Although her main objective is to get back the path data as how it was shown at before 0.9-v2 versions and which was abusively eliminated by PeterSt, she unanimously votes for the same ideas.

When the anit-CTC, thus far known under the name of aCTC, gets recognition by the U.S.A. administration, she will put an official complaint, but, she might need the votes from the CTC and therefore politely asks the CTC to join her and form the CTCaCTC which even might go for president when enough followers sign up.
Subscription is free.

Just found (and solved) it. Indeed it's not working on XP anymore.
For XP users : Please untick the CoverArt as Wallpaper checkbox so you're not bothered by the messages, until the next version is up.
I can't put up a new version right now because of some radical changes.

Edit : Actually it is Engine#1 and Engine#2 where this goes wrong. So for those Engines on Vista it wouldn't work either, currently.

I know, coverart can be embedded in files (MP3, even in WAV I think). Currently this is not supported.

About the XP thing ... I must sort that out. It is true that this time development was at a Vista machine, so I didn't notice things changing on XP.

A new version of the development environment has been used. This implies that you could encounter unexpected problems. If so, please report as detailed as possible. Thanks.

All for all Engines except for the last subject :

• Played tracks are kept in a special Playlist named !Played.PLXX
  This might come handy when you are looking for that track played "last week". Just load beforementioned Playlist and it should be there somewhere.
  Currently 1,000 tracks will be kept; in a future version this may be a user setting.
  
  
• Before Folder.jpg files were recognized for CoverArt. Today each name with the extension .jpg or .jpeg is recognized, even if the files are being stuffed way down in sub folders connected to the Album Folder.
  Quite some "intelligence" is applied in order to show the one and only cover, and you probably will be able to find examples of that intelligence being off.
  Might you be seeking the algorithms used, currently files larger than 1,200,000 bytes are being skipped at all, unless it's literally named Folder.jpg or Folder.jpeg.
  The challenge here is/was to keep things speedy.
  
  
• Above mentioned coverart and coverart folders are now copied with the Physical Copy functions (this was actually wrong) as well as with the "Add to Galery" functions.
  When a Galery is used as the source for making another Galery, the folders containing coverart are currently still not copied. This will be done in a next version.
  Edit : The latter is not true. This too has been arranged for.
  
  
• The the line of the above, it is now taken into account that coveart needs not to be (near) square. For instance, when an inlay is folded open this will be nearly twice as wide opposed to height, and everywhere this is respected.
  One of the places this occurs is the Wallpaper of the desktop, and it was not tested what happens if an e.g. 1200 x 600 picture is set as Wallpaper on a 800 x 600 display.
  
  
• Everywhere where pictures are shown, they are rendered to the best quality now.
  
  
• The Library Area now is provided with a black background.
  
• The Physical Copy functions have been extended with Copy WAV To FLAC and Copy FLAC To WAV (rightclick on selected items in the Library Area and you'll see the options).
  For Copy WAV To FLAC compression level 5 is used by standard, because it's really fast (enough) and a higher level slows down significantly without real gain on compression.
  Note that these are actualy Copy functions with the feaure of when the target not being in the format as implied, the source it will be converted to it. IOW, all files within the selected structure will be "copied".
  
  
• 
  The ever invisible split bar which (if you knew that it was there and you knew where it was) can be dragged left-right to let shrink-grow the CoverArt picture on the player, has been made visible. Don't forget to drag the bottom of the form downwards as well when you want to have the CoverArt picture bigger.
  
  
• Since the combobox for the Engine setting moved to the Settings Area, the checkboxes for Double, Invert etc. actually never were consistent with the real situation anymore (like which Engine allows for what). It was found that a technical error from the development environment caused this, and now this is solved.
  
  
• Minor changes have been made to the ChangeWP program, in order to (hopefully) better show what's going wrong if something goes wrong (a few users report problems in this area).
  
  
• Since the before version, the bitrate of FLAC showed as 1. This has been solved.
  
  
• At a new version of XXHighEnd always the user settings get lost, hence they must be set again;
  From now on, at a new version the question is aksed whether to use the old settings, which can always be answered with Yes. Only when that incurs for (inconsistency) problems, answer No.
  Note : The FormPositions cannot be retained at a new version. The position of the splitbar (see before) goes along with that.
  
  
• The Data Folder Setting (Settings Area) could be entered without a "\". Like with the other places, this is now auto-added when forgotten.
  
  
• Before, when XXHighEnd was (somehow) quit when in the Minimed state, it would re-appear like that at the next startup, and it needed some hussle to get all back to normal. Now this has been solved, although the XXHighEnd form will then start in the original position and size (like right after an upgrade).
  
  
• It appeared that when the Libary Area was used with the Chk checkbox ticked, no differentiation in color was made between WAV, FLAC and MP3 files as usual, as well as that no "(WAV"), "(FLAC)" and "(MP3)" indications where shown underneath the pictures in the case of the items shown being folders (when the items are files this is no problem because of the shown extensions).
  This has been solved now.
  
  
• When XXHighEnd was brought up after or during Unattended Playback, the CoverArt picture shown in the player was always from the last track in the Playlist;
  This has now been changed to the first shown selected track (which is the one currently playing when Playback is going on).
  
  
• Since the last version, moving the split bar (see before) messes up the screen unintendedly and the combobox for Playlists went all over.
  Solved.
  
  
• When a T for Track Search had been entered in the field next to the Search field (Library Area), and the T then was removed (and not filled with an A(lbum), the next press on the Search button kept on searching within Tracks. This now is restored to Albums (and an A is auto-shown).
  
  
• The picture indicating "no CoverArt present" has been changed into a more "XX" one.
  
  
• In the previous version the saved structure of a track added to a Galery from within the Playlist Area was changed under the remark "there should not be any structure at all". This was wrong because now there was no official space for CoverArt. So, things have changed again and now it's OK.
  
  
• An "escape" was found where Engine#3 could stop playing without message. A message has been added for this ("TEMP ERROR C").
  Another message - which had been eliminated before because it seemed to be without reason, has been reactivated ("TEMP ERROR B").
  
  

Edit for XP (and Engine#1 and #2) users : In this version CoverArt can't show as Wallpaper. So please leave the checkbox Show CoverArt as Wallpaper (Settings Area) unticked for now.

Keep in mind though that the Fireface (at least the 800) has two SPDIF outputs only, one coax and one Toslink (or two Toslinks ?). Thus, connecting more DACs (with amps behind them) is a bit of a strange operation.
A less strange operation occurs when you use the analogue outs from the FF directly to the amps. An again more awkward situation emerges when you combine this with using one SPDIF, and use this for one of the XOver channels (though stereo).
Fact is that the FF just can do this, as long as you use ADAT (which contains 8 channels).

In either case a digital volume would be the most convenient, but assuming 16 bit output towards the DAC this should be avoided, unless the digital volume of XX is being used (and then preferably not more than -18dB).
The real problem would be the individual volume of the XOver output, which should not occur in the digital domain with 16 bit output (24 bit is ok). Don't get tricked by the bits used for internal processing; it is about the output (or IOW the input to the DACs).

Quite another problem could be (or will be ?) the lack of drive, because of no "buffer" being present. This by itself urges for the pre-amp again, which now must be multi-channel (but obviously without processing). And once the pre-amp is there anyway, the problem of the digital volume is not there anymore (but it requires the pre-amp to attenuate in the analogue domain).

So it's not all *that* easy, but the base is there.