XXHighEnd - The Ultra HighEnd Audio Player
February 07, 2016, 01:49:15 pm *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Dec. 31, 2012 : XXHighEnd + Phasure NOS1 DAC receive 6moons Blue Moon Award !
** "Lonely at the very top" **
Search current board structure only !!  
   Home   Help Search Login Register  
Pages: 1 2 3 4 5 6 7 8 [9] 10
 81 
 on: February 01, 2016, 08:44:22 am 
Started by hbrew - Last post by PeterSt
Steve,

Maybe you are (or have been in the past, read on) pestered by a UDF formatted device. Can be your NAS ...

On a side note because nobody will understand, including me, is that :
or you show a different source in Explorer from what you loaded into XXHighEnd;
or this is FLAC and the Track Numbers are in there.

The latter is sort (pun) of what you implied, although you never told it was FLAC. So it is my guess it is and it contributes to the confusion. Now, let's see in here for an example of similar (not the same !) :

Wrong order in Playlist Area ?

There are more topics about the phenomenon, but the one behind the link above makes it quite clear (ahum). Otherwise search the forum for UDF and user PeterSt and you'll find a few more, with the notice that this is all solved by now.
Not yours ...

The problem summarized (technically)

When a folder is scanned for its contents, the result is *always* brought forward by the sequence of creation. Regarding this you may just as well think date-time although often the time (minute) is the same. So it really is so that physically it is written to the table of contents in the sequence all was created.
There is no way around this.

It is read back in the sequence which is stored in the table of contents.
There is no way around this either.
Notice that I am talking about the programming functionality which "enumerates" the contents of a folder. This would work the same as when you start explorer for a folder and you never sorted it exlicitly on anything. So yes, you can sort explicitly, but the programming facility which "enumerates" can not. We can sort afterwards though, just like in Explorer.

But we don't want that ...
Things would go bad when two albums are in the Playlist and first we'd have track 01 of the one, then track 01 of the other, then 02 of the one, then 02 of the other, etc.

The problem summarized (functionally)

Where it goes wrong is at some "source point". Thus, if you are "capable" of having a wrong sequence - and which is possible by leaving out the track numbers and now sort it on Name (which is alphabetically) and *then* copy it to elsewhere, the copying goes by alphabeth sequence and at the other side it ends up in that sequence written. And now you can add track numbers what you want, you will not be able to let change the enumerating program facilities the sequence of coughing up. It's like the table of contents of a book being mixed up and writing the chapter numbers with pen next to it (at the left side) won't change the printing of the page; It is too late.

Solution

When you took (or want to take) the effort of adding the track numbers to it anyway, then sort it on alphabetical sequence (now it looks all OK) and from there copy it one time. Now the copying process will be in the proper sequence and at the other end the table of contents will be in the proper sequence as well.
And now it is normally usable.

And solve a bug ?

Nah, not a bug. But what you showed is that XXHighEnd *is* able to come up with the Track Number, which is stored internally in the FLAC. So yes, I know I made that, ever back. Now :
If you look at the other topics (apply mentioned search) then you see that more of such anomalies could be solved, like the HD Tracks fine (stupid) sequence of 1,2,3,4 instead of 01, 02, 03, 04 which all is fine when less than 10 tracks. But when more (like 12) it is going to be 1,10,11,12,2,3,4. IOW, there sure *is* explicit sorting in there, but I guess that happens before the track numbers are dug up from the FLAC header data. So that is not convenient.
And if it isn't clear by now : in such a situation the tracks are - without track number - in proper sequence because they were written (!) in proper sequence by the ripping software (which just starts at the beginning of a CD).

All together it is error upon error upon error which lets this fail.
I can look into it, but expect it not to be solved fast (has to wait until the next version (2.06)).

Peter


PS: Please explicitly confirm that the track numbers you showed in XXHighEnd are NOT in the file names and that they have to come from FLAC. If you are not 100% sure what I'm asking, please say so.

 82 
 on: February 01, 2016, 12:05:04 am 
Started by hbrew - Last post by AlainGr
Hi Steve,

I noticed this in Windows explorer, so when I rip my CDs, I always ask for the tracks to be numbered with a 2 digit mask, like:
01 xxxx
02 dddd
03 aaaa

I exceptionnaly had to use a "999" format once, since the download was containing more than 100 songs... 001, 002, 003, etc...

You may not like that numbering in certain situations though...

Regards,

Alain

 83 
 on: January 31, 2016, 10:22:25 pm 
Started by hbrew - Last post by hbrew
My name is Steve.

Attached is doc in Rich Text Format with screen shots from Explorer and XXHE. Both are in the same display order (alphabetical) not track order.

Thanks.

 84 
 on: January 31, 2016, 09:01:12 pm 
Started by michaeljeger - Last post by michaeljeger
Peter

Many thanks again for helping sort this out.

I am now happily enjoying some amazing SQ again.

Now I even detached the RAM OS drive from Computer.

Really nice.

Regards, Michael

 85 
 on: January 31, 2016, 07:38:29 pm 
Started by Gerard - Last post by PeterSt
Bert, that is because you set the date *after* the date of birth. Of course that works normally - why wouldn't it ...

And why would it expire ... it is an RTM version.
Happy

You can't see it, but Gerard was talking from the context RAM-OS ... (which includes 10074, which ... ... OK ?).

Regards,
Peter

 86 
 on: January 31, 2016, 07:19:02 pm 
Started by Gerard - Last post by BertD
The October 13 comes up because that was the Release Data of 10586.

Today I have installed 10586.0 using the present date and related to that all seems to function normally even after many reboots...

No idea when or if it will expire but setting the date to 31st of januari seems to be no problem.

I will reset the renew date to today... or not ;-)

Bert

 87 
 on: January 31, 2016, 04:49:32 pm 
Started by michaeljeger - Last post by PeterSt
Ok, solved.
At this moment it is only that we can't tell what exactly happened, except for that something can have happened to 3 files in there, without really being able to see what (but I stored the originals in there again).
It can also be that I am better in rebooting, but although I have much experience with that by now, this is highly unlikely. Huh !?

We took some precautions to see better what happened, may it happen again.

Peter

 88 
 on: January 31, 2016, 03:40:39 pm 
Started by michaeljeger - Last post by michaeljeger
ok Teamviever is installed.

I sent you the password and id.

I will send you pw after each reboot.

Regards, Michael

 89 
 on: January 31, 2016, 03:24:47 pm 
Started by michaeljeger - Last post by michaeljeger
Hi Peter
The whole thing hangs right after the first boot menu.
So as soon as the first selection is done (Win8/Win10 RAM).

I do not even see the second boot menu after the first one.
so it hangs right after the first one.

I will try to install this Teamviewer

More to come.

Regards, Michael


 90 
 on: January 31, 2016, 02:55:03 pm 
Started by michaeljeger - Last post by PeterSt
Quote
Michael, when you boot into your backup image

Michael, before you *really* boot in your "backup image" ... (never do that !!) ... I am pretty sure that Brian means the BASE OS. Or whatever else, but not the explicit backup of the BASE OS. Ok ?

Thank you Brian ... not a bad idea at all ! But then from a slightly different angle. But I don't know ...

Peter

Pages: 1 2 3 4 5 6 7 8 [9] 10
Powered by MySQL Powered by PHP Powered by SMF 1.1 RC2 | SMF © 2001-2005, Lewis Media Valid XHTML 1.0! Valid CSS!
Page created in 0.266 seconds with 15 queries.