I am writing this in advance of the upcoming (0.9q) bitrate indicator for MP3, which does not workout as intended, or better, the promised bitrates in MP3 files do not work out ...
On another note I personally wonder what is going on;

What XXHighEnd does, is calculate the effective (!) bitrate opposed to the filelength and the duration (play time of the track). With this, the sample rate (44100) and bit depth (16) is assumed. Now, CBR (Constant Bit Rate) 320 Kbs (as officially indicated in the file header) files turn out to be anything in between 224 and 320.
Files, officially indicated as 256 can also turn out to be (near) 320, although this is more rare (i.e. usually the effective bitrate is lower than indicated).

I did not try to create MP3s myself in order to find out what's really going on, but is this a known phenomenon ?
Are we possibly hoaxed at downloading files with a presented too high bitrate ? (think of AllOfMP3 -> MP3Sparks where you pay more the higher the bitrate).

Am I missing something ?

Hi Andrey,

I understand your wish for this, but it can't be helped. It's an XP limit in the driver area.
The only thing you could do is get yourself a Fireface400 and use the MME drivers from it. It would be bitperfect in the mean time ... (but you wouldn't be able to alt-tab and back to XX, because then sound stops).

So it's either the 64MB limit, a Fireface, Engine#2, or Vista ...

Peter

Well, if I have that myself (as described in the buglist) ...


Of course I believe you, but now ... how "legal" is that file ?
Would you be so kind to PM me an example ?
Sidenote : AFAIK (or intended) all MP3's should play (opposed to FLAC (as explained elsewhere)).

Thanks Gerard.
Peter

Hi Gerard,


That's normal for MP3 (in the case of XX).


These are described in the buglist ...


I have ...


Which is not the case in your xx2/xx3 example. No times ending at .00 in there.


What do you mean ?

a. I rely on this :


b. By now I myself did not run into any problem (including VBRs indeed).

Peter



PS: Please do not alter the subject of a topic, and then start mixing (up) everything in there ...  I split the topic and changed the other one back to its original title.

Gerard,

http://www.phasure.com/index.php?topic=234.msg1393#msg1393

I'll try to brew something for y'all. But please keep in mind : this cannot be about SQ !

I am very sorry, but it can't be done (and the Guest thing appeared to be a mistake; it ran Engine#1 (but told 3).

Again I tore down everything in the software - but now for this situation (in my case the samplerate (your case would be the bitrate)), and again I bumped into this one "kernel" call where things go wrong.

On the other hand, you *must* be able to play 16bits. Note that you'd be feeding something into the stream (some DSP thing ?) when it outputs in 24bits only (or inputs ??).
Also note that when you'd manage, you will still be dealing with the Exclusive Mode thing (unless the same culprit causes that too).
Although there will be a difference in playback from Engine#3 opposed to the others, when all is subject to resampling (which it would in shared mode !), all is lost already, and you'd be "as worse" with Engine#1/#2.

I give up ...

96dpi is equal to the screen resolution (for most displays). What you get from that is a 1:1 physical equally sized picture (and 460x460 or so size).
I don't JPEG the h*ll out of it (I leave everything at max quality which would be "1:1" for JPEG and the least compression).
24bit colordepth is fine.

This brings 150K-250K files.

Ok, I am as far now that I have your behaviour again;

Could you try to login to your PC as Guest and try again ?
I did not look for the differences yet, but logged in as guest (hence no admin rights whatsoever) it works, and with those rights (but not uplevelled) it does not.
Also though, with guest I have less devices (only loudspeakers, which btw I try to use, like you; with admin rights I also have SPDIF).

At first glance ... strange.

Bad luck so far. The laptop now just plays (at 48K/16). So now I can't try to tweak it ... 

But before it did not (Engine#3 of course) so I'm not sure what changed ...

It's my pleasure Russ. 

The Next/Prev buttons is a know phenomenon (which btw has been solved before but came back due to the specifics of this kind of control of the files).
It's not on the bug list though; I'll put it there now.

Peter

No idea really. But it would hardly be true that 16 bits is not "allowed" by your card.
What about things like unchecking "IP Voice" ?
Or any other means of which you can expect to actually "downgrade" the card ... ?

You chose 24 bit. Should be 16 ...

As said in another post ... this is unintentional (hehe), but I just slowly learned *that* these kind of changes influence.
By now the pile of code has become too large to change for the better on a Friday night, but it will be done - and then in a fashion that those influences stay out.

Get yourself a nice weekend by returning that soundcard ...

I am very sorry, but if I'd know what to do I would have told it. Actually, at getting the WMP rips to work (Version N and source problems) I broke down the device allocation as far as I could (this stops when "kernel" programs are called, which are out of reach) and something like this cannot be tweaked. Ok, not with my current knowledge. I thought about you as well, but it just can't be done.


Your last post shows that your card does not allow exclusive mode for the driver you chose (probably analogue-out (Loudspeakers)), and *then* you run into the problem that Vista always resamples (it even will do that from 44K1 to 44K1 ) but Vista settings do not allow ... err ...  44K1 in your case ?

At writing this, I now realize that something else must be going on as well ...
(keep in mind, the real culprit is the Exclusive Mode not being allowed)

If you are sure that you're feeding XXHighEnd with 44K1 material, something in your system does not allow 44K1.
BUT ALSO SET THE OUTPUT TO 44k1 (in this post) you actually showed a WRONG setting, while I in the post after that pointed out that you should choose 44K1 in there. Did you ? can you ?
If you can't set things like I showed here, and if not indeed where you most probably can choose 48K only, your card will be resampling to 48K, and ... and now I don't know.

Something else is wrong, because it should be possible anyway to let Vista resample. Example : if *I* resample to 88K2 (Engine#2), Vista will make 96 of it. I think the kernel programs somewhere must be in error *OR* the reason why it is not working is not clear. Look at the last screenshot you showed : "Device cannot be allocated because of nor matching sample rate (?)" ... note the question mark, which shows that at that point I myself cannot determine the real reason for rejection, while actually I "ask" for a sample rate to be fed.

Background : When in Shared Mode this is about, say, KMixer which will indeed mixes several samplerates to one common denominator, and whether this is needed in your case or not, it tells me (the program) it can't.

I have a Vista laptop which shows similar behaviour, BUT, that does not allow 44K1 as a choice. It still should work as per explanation above, but it does not. Exact same messages.

Please answer the question whether you can choose 44K1 in that screen I showed.

I could use the laptop to tear down the problem ...



PS: Sorry for being a bit fuzzy, but this kind of brainstorming helps me to set things better in my mind.