Hahaha , uhhmm ...



Very good that you solved it, but *this* really is a problem. A dangerous one ...
Since your original problem apparantly is unrelated, this is rather off topic now, and maybe I'll split this post to a new topic. Anyway :


What happened here, is that because of insufficient rights -or whatever it exactly is that caused this for you- your files weren't copied to the location you indicated, but to the shallow file copy area (my wording) Vista invented for you. There is no way you can see this other than looking / checking you just did. However, there are some things you really can't perform on them, and one of them would be the dragging + drop in certain situations (which situations I never recognized). A pain for sure would be the inability to open the file in read/write mode, which immediately would let die XX.

The latter took me virtually months to solve because a. I did not even know the files could go there and b. the open for read and write (the latter) caused this. This by itself was solved by me by opening the files for read only (which really is sufficient of course), BUT now you don't notice anymore that it happend (what ? -> the fact that the files are really somewhere else than you copued them to). So :

Your files just aren't in the place you think they are, which is really, really dangerous.

Maybe currently I don't have the time or rest to work this out properly (kind of over 4am here) but it would mean that when you e.g. have an external disk where you wanted the files, they just are not there. Hence, detach the disk, bring it over to somewhere else, and they just are not there ...

This phenomenon is "official Vista", although I forgot why this really is. But :

Once you "created" this situation it will keep on doing this.

The one and only solution is to locate the physical location like the Dos box showed you (you can go there by Explorer just the same), and delete the subfolder one level up (I forgot how it is called, but you will automatically see which one it is). Do note however, you will be physically deleting the files ...
And I'm not sure whether it is even possible to copy them from there to another safe location first (they could end up in there *again*).
Once this subfoler has gone, you can safely start copying things as usual.

As usual ? well, that's what it is ... That's what it is that I don't know. For example, I could incur for this by copying files from my USB harddisk to the C:\ drive. It's a kind of Vista protection mechanism, I dunno ...
Remember, the USB disk is one example, and I am sure there are more (because I encountered it more often).

A nasty Vista habit, which is not even a bug ...

Did anything come from this (hence did you try these things ?  )

... but I didn't see it in your signature. . But it still was a hunch. Maybe I'm good at that, hehe.

It's because of the different means of interfacing the two USB processes use; same as that it's not allowed to use USB storage together with an USB DAC.

Btw, I don't know anymore that - and why I advised USB (probably because you only have an SPDIF interface on the motherboard only ?), but generally ... use the one which sounds best. Of course this depends on the DAC just as well (and you know best for what is which on the DAC ).

Good Chris.

Anyway, I should anticipate on jpeg just the same. I will change that.

I was just working on a screencopy of this. It's the top choice, in english something like Hide extensions for known file types. It should be UNchecked. Just for your conveniency so you can see how it's acually called. You'll see a possible folder.jpg.jpg too then.

You can try this for your current problem folder to start with. Later, you can do it with the top most folder (and then hope all subfolders inherit the setting; if not, that's another setting somewhere ...).

It was just a hunch ... however :


I thought you use SPDIF ? (see your signature). If you use USB to connect your DAC it's even logical that this happens !

Hi Johan,

When the hickups happen, do you see the disk activity light flicker at the same time ?

Supposing you have USB connections on the front and on the back, does it change things when you use the front or the back ?

I agree with you fully. It's only visible so badly because it is disabled, which by itself is temporary until I've implemented dragging it for repositioning.
But I will make something more visible of it.

Hehe ... never knew this was about music. As you might expect ... "our" PC's have all sounds from these sources disabled ... like yours.

Test your glitches !!

Uhhmm ... I'll workout something. Must go now though. I hope you can wait till tomorrow ...

Dave,

Don't be afraid when you wake up I deteriorated the SQ ... Me, and we all will protect that (if "you" find the SQ went down, I'll roll back to the then previous version).
Besides that my last post here was about emulating a similar situation in order to tackle the Vista/64 problem. So don't expect strangenesses.

Btw, why these references to IMHO unrelated youtube stuff ?
Also, please keep in mind that this board is less for "interesting music" as such, and more for indicating problems with XX, or where it excells (and upload a piece of track). But I guess your nice posts make me forget that ... 

Regards,
Peter

For others : Keep in mind the importance of this !
It is just not allowed to use USB for your DAC on one hand, and use USB for retrieving the track data on the other. Both means of USB processing are different and conflict !

On the other hand, the problem would be relatively minor at using XXHighEnd, because of the asynchroneous reading of the track data. However, it still might bother at the end of tracks (when a next track will be read).

Hi Edward,

I can't be sure, but this looks similar to having the program sit on one PC and run it from the other. That won't go either. I never found why, nor did I try hard to. It's even inconvenient for developing, because I always have to copy a new build to the PC I want to run it. Anyway ...

Since the message is very general and the program just won't load in such a case, it could very well be that if I find the solution to this "remote" running, with Vista/64 it will run just the same ...

Possibly on Vista/64 there's an official "distance" between the OS itself and its disk subsystem (still being 32bit ??), so it indeed comes down to the same cause then.

What I will do is try to find out is what causes this remote running not to work, and proceed from there.
Thank you.
Peter

Hey ...

Well, allow me to say that I loved reading your story. Really nice.
Okay, a few responses :

In Vista (with #3) you really don't have to shutdown anything in order to avoid KMixers and SRC's and all. XX goes 100% sure around them. But, if your soundcard allows it (without soundcard it should anyway). You can test that by sliding the Vista volume sliders, or shut off the sounds at all; -> when nothing changes you are good. Also note that the samplerate settings in Vista won't be respected either (and that's good).

Then, the quality of "complete CD WAV tracks" will not be different from the small tracks. As a matter of fact, for months I could use this means as the only means myself. No problem.

So on to the hot item : the cue files;
In another thread I already promised you it wouldn't be a problem. And it is not. Including tracknames, as long as you can see them in the withgoing cue file that EAC creates (it's just plain text). You will be able to select and play the individual tracks, and have the coverart visible (assuming you or have it somewhere, or have it stored in the cue data). The only problem for now is the priorities I must deal with.

According to the latter : I just finished the base for decent gapless playback (which doesn't bother you currently) (btw, Engine#3 only), which most probably will be uploaded this weekend. Right after that I'll implement FLAC as a first supported lossless codec, but I really can't tell currently how long that will take. I mean, it will be "forbidden" that the process of decoding influences the sound (which it ussually just does, no matter those who say this is not so -> just listen better ) and I really don't know how difficult that is going to be.

If no other things come up in the mean time, I'd say that the support for cue files is next.
(in fact there are many other things already, but these have a lower priority).
Btw, the extraction of the individual tracks from the large WAV will not "be able" to influence SQ.

Peter

Just for fun ...

Officially this even can't be solved. The phenomenon "album- / tracktitles" is coming from the whole world to you, while you will use one "code page" (to type your own text etc.) hence the all over the world "typed" tracktitels can only be interpreted by their respective code pages. Unsolveable for practical reasons.

The stupidity here is that writing such "text" as a filename to disk *is* solved by the Windows OS. I'm not even sure how (and why exactly), but this will be related to the phenomenon "system string". All things go wrong when you write the same filename as data in memory or a textfile, which then has to be done in Unicode (allowing for just all characters from all over the world) but which needs interpretation "for which codepage" at reading back. The most stupid of it all is, that I don't really care what that russian trackname really means, but when the characters change on the way, the filename can't be found anymore (not in C++ and not without very ugly programming).

Ok, I solved it, but it could only be done with a big trick.