For those who have MP3's around and want to play them via XXHighEnd, here it is ...
(.MP3 extension only)

More importantly however, chances are high that you find MP3 playback via XXHighEnd to have a better SQ than you are used to. Anyway, it should from theory. By far ...
For those who play MP3's ... please let know your opninion.

As with FLAC, currently MP3 files can not be searched for in the Library Area, nor can they be used in the Galeries.

VBR (Variable BitRate) files were *not* tested. If they don't work as they should, you will notice this by a wrong indication of the duration, which goes along with a too early stop of playing the file when the duration is indicated too short, or currently unknown anomalies when it is indicated too long.

Gapless was tested and found ok, but do note that this greatly depends on the source material, and last parts of a track are very often cut (at encoding to MP3).

Obviously it is handy to show the running bitrate (at judging quality), but currently it's not there.

It can be so that Cue encapsulated MP3 albums (etc.) just work (thus, a Cue File with MP3 in there), but it was not tested.

In future, improvement on SQ especially for MP3 (and other lossy formats) are to be expected.


This has been the last upgrade on, say, more major new functionalities, and now first the running bugs are going to be solved in order to get a final 1.00 version.
No bugs were solved in this 0.9p version.


Edit :

Because of the duration calculation (and the means this currently is done), MP3 tracks do not load as fast into the Playlist Area as WAV/FLAC. For one album this takes 4-5 seconds in a well performing system, but with a less performing system (mainly in the disk I/O area) it may take 20 seconds or even more.
It can be expected that in a future version this will be solved (with low priority).

Ok, all clear. Thank you.

Headache ? oh no ...

Below quote is from one of the first posts I put in this forum : Why XXHighEnd ?


Now what ?

Take it that I know exactly what you mean, although I don't suffer from this myself. But let's say that I know -without you telling it- you can't even watch a movie in the cinema because of this ...

Andrey, from this point on you are a most valuable user to, say, all of us. Of course with this I don't say that other users are not valuabe, but you are able to hear instantly about jitter, where "we" need maybe days to judge the implications of it.

There is no jitter, bad jitter and good jitter. The first must be seen as impossible, the last as what to achieve, where I *take* it, that what is good for you, is good for us just the same. This is no science, so I assume it.

Now let this be off topic : how do you compare Vista with XP on this matter ?

Don't let me interrupt your question to the others, but more or less off topic I can say this :

Since Vista is the development path for XXHighEnd I kind of neglected the XP version. More stupidly : what I now use to keep the SQ constant for Engine#3 (hence Vista) just influences SQ from Engine#1 and #2 (both XP and Vista). But :

That it happens like this is just the conclusion from people reporting degraded SQ in #1 and #2, while I actually did not change a bit to the core engines. However, as I learned during time other stuff just influences, which slowly gets under my control. On that matter, I will rebuild the #1 and #2 cores in a fashion that "external" influences do not so anymore, with for now the question how that will turn out for base SQ anyway ... (could be better, could be worse).


For those who were so kind to report differences in a next version on #1 and #2 (like in fact you just did Andrey) :

I am really sorry that I did not do anything about it (described above as "neglected"), because I really did not know what could have caused the difference in subsequent versions accordingly. Mind you, when I started this all well over one year ago, I had explicit means in mind which worked out. During time however, I learned that more things influence than I could have guessed. Also, the more you report these things, and the better you can describe the differences, and withgoing your systems used in your signatures (!), the more I will be able to draw conclusions from all of it.
This really is of the most importance, where engineers et al *know* that SQ can't be influenced by means of (no DSPed) software, or anyway don't have an explanation for it.

I can only emphasize on the fact that "we" are developing this player together, where I myself on my own am unable to listen to all various settings, and of course don't have your systems. I must work with your input, and I *will* do that.
Drawing kind of decent conclusions needs as much input from you as possible. Never hesitate to "complain" !

Peter

It is not so easy for me to read this ... Maybe with some other wordings you can list again what when etc. ?

Unavoidable question : you did re-tick the Core Apopointment checkbox and did not forget to re-assign priority ?


If you think of what "installed" means in this case ...
Please think carefully wheter you did not change things in your environment (I know this is a superfluous question, but your quote above leads to it ...).

I'm open to it anyway.


One more thing :
Indeed I can imagine SQ changes with your WMP rips. In the current version it would even be a mistake on my side. BUT : How do you compare things anyway ?
If you only not listen to WMP rips now, *OR* did not re-rip especially to listen through XXHighEnd and all the so many "mistakes" which can be made, and which makes apples and oranges of things.

Small brainstorm and background information :

First off, this dialogue has already been there, but I eliminated it.

There is more going on than just "do what you like", or "let the program behave to what you have";
Many things (if not near all) are about standards. Thus, e.g. assuming that many software anticipates on folder.jpg, it would not be wise to choose something else. In approaching your data you would be bound to this one software that is capable of dealing with ÿour "name", and all of the others won't work (upon your data).

Where above is already a good reason to use one name only (folder.jpg), there's many more reasons, of which only a few are so less ICT-related that thay can be explained. Sort of;

A text field indeed could hold the name you use. Technically, for everything in the program, there would be no difference whatsoever, when the data has to be approached "through" this field.
But now there's two names, like folder.jpg and folder.jpeg (and this is practice). Yeah, we could enter both in the text field, separated by a semicolon etc. But *now* the program is in trouble.
For everything that approaches the (existence of) coverart, it must try all the possibilities. Oh, by itself no problem, but since (obviously) at some start of programming this is not anticipated upon, a few things have to be changed.

And ICT mind now says : the latter is no problem, because the first ("standards") already determines that it should not be allowed.

Now think further :
Whether we use Dos "dir *.jpg" or Explorer and sort on extension, we can only and ever choose one type, right ? Now this is THE reason why you should not want it otherwise (I mean, do not use two or more types mixed).

From this follows that you are "allowed" to use one type only, and that could just as well comply to a standard, if it's there.

Done.

Well, not completely, because *now* you must have the ability to change things fast, and for that matter what Gerard came up with might be good for a solution (I did not try it, but I assume it works satisfactory). If this does not work nicely afterall ... I planned to have something like this in XXHighEnd anyway (like a boatload of data manipulation functions will be in there eventually, the deletion of coverart being a first example currently being there).

So ... all done now ?

Sadly, no. But from an unexpexted angle;
If you look at the principle of the Galery phenomenon, you 'll see (or learn) that it urges for mixing everything and all, and that "albums" as such are just a carryer of data. Yeah, physically you would store each album in its own folder, but from there on it doesn't do much anymore. I mean, if you'd create "Blues Tracks" and stuff all the according in there, the album as a carryer has gone.

But now there is a small complication;
Since we are able to deal with FLAC files, they will mix with WAV files. And this urges for the same problems as with the folder.jpg thing. This time, however, it is unavoideable; We can't rename everything to WAV.

The complication in the end is a technical one. Thinking of the "dir *.wav" is similar to the search options which can be used from within the program. It can't do "dir *.wav" and "dir *.flac" at the same time. It has to be two subsequent searches, taking twice as much time ... Or 10 times, when 10 file types are supported ...

If this is approached wrongly with the example of "dir *.*" you'll get the search result from Vista itself (by typing in the search field in the upper right of Explorer). You'll get albums and tracks and coverart mixed.
I don't say that our Bill did not understand, but I do say there is more to it to get these kind of things right.

Anyway you know now why the release note on FLAC says that it isn't coorporated in the search function at this moment ...
This must be setup decently.

Lastly the unexpected conclusion : when the wav/flac/ogg/mp3/ape whatever is solved decently, there is no reason anymore to apply the same to the folder.jpg et al.
The only thing left to decide for that is the "standards" thing again.

Peter

Gerard,

This is about extracting the length of the track from the data. So, e.g. the Sinead can just be converted, but the length data is in another place I don't (yet) anticipate upon. Thus, all would be okay when you'd just did not need the tracklength in advance. So it errors out on that only ...

As I said (similar) in the release note : genuin FLAC only for now.

Gerard, thanks for the information. The thing on the timing (track length) would be normal behaviour when things go wrong as they do here.

Then, the Sinead O'Connor seems to be a FLAC which is encapsulated in an MP3 ... Anyway it contains ID3 tagging.

The Dulfer I don't know yet. I will look at that later this week.

It might not be the best idea to let these downloads loose on XX. You won't know what you have, and my time for these analysis is kind of "priceless" at this moment. I mean, since all these weird formats aren't supported anyway ...

After you saved your copy into a file (PNG is best) :
See below ...

You could use the printscreen button (with ctrl, alt or shift I think, and each with a different result) and copy it into a Word document which you attach ("Additional options"). But it's awkward and Word will resize it.

I use SnagIt, which just does all you could ever want. But it's not free.

I think I heard others about other programs (free), but I forgot how and what ...

Well, why not. Actually I'm already having quite some fun with the preparation of this subject, learning where/what can make differences.

"The best sounding MP3 player" ... it actually makes me laugh. I hear a few contradictions ... On the other hand ...

I can tell you that there is at least one user amongst us who has as large harddisks as "we" have, but where we fill those with WAVs he has them filled with 320 kbs MP3s. A couple of thousand albums similar to mine, but accidentally ripped when the HDDs where too small to contain full WAVs.
So why would such a user not be allowed to have the best SQ of his library, consisting of MP3s ?

Let's see whether I can do it ...

Correct. Since the 0.9m version and Processor Core Appointment - working with Engine#3 only - it would.

All can be done, but it really would be, say, stupid to do, since the SQ coming from Engine#1 and #2 is already miles worse opposed to Vista/#3.
I think you can test this yourself ...

So, applying FLAC for #1 and #2, OK, but without the effort to let it sound "the best".

Hi Andrey,

It is rather easy to add FLAC for Engine#1 and #2 weren't it that the way all is consistently setup will induce for timing problems on gapless and cpu useage that influences sound. For anyone who is not bothered too much by these aspects ... it can be done.

But hey, I'm already anticipating on MP3 support now , so why not ...
 

Hi Gerard,

Yes I received your email. Thank you (you can remove your links).

What it was ripped with is less important I think. More important would be what they FLACed it with. If you know that, you can try to FLAC a CD yourself with that same tool, and when that (is or) is not working it is important to know.

Be careful that you are not dealing with containers like OGG or even MKV. Probably many programs will be able to deal with those just by renaming them to FLAC, but XXHighEnd currently does not dig that (it will, but not now).