Windows Vista configuration issues

[Simon Chick]

I am trying to sort out the best set-up for my digital music playback, while running Windows Vista.

 

I have been registered on this site for a while and have read extensively in the forums here, but this is my first post. I’m afraid it is also a very long one.

 

I keep reading that XP is better but that Vista ought to be better, if implemented properly, if there is a WASAPI plug-in being used, if …, if etc etc. However, none of the posts clearly and authoritatively address my issues, which are all essentially “How to make the best of Vista in a real world HTPC?”. I suspect that quite a few others have similar set-ups to me, so I hope this thread will provide a central point of useful information for all of us.

 

In part my quest is based on obstinacy, as I want to use a PC running Vista, I want to use FLAC files and I want to use Media Monkey as the interface. So there is no point in saying words like iTunes, Mac and Foobar to me. I’m not interested! Nor am I interested in the extreme set-ups using XP stripped back to minimum, legacy drivers etc. The PC is required for other HTPC duties too, and I refuse to accept that I cannot still get 99.9% of the audio replay quality that the extreme rigs can achieve!

 

I have a large (approx 40,000 track) music collection, almost of all of which is EAC-ripped and in FLAC, and residing on a 4TB Infrant ReadyNAS NV+. It is delivered across a wired gigabit ethernet home network to a self built PC in a Zalman TNN 300 case, selected after about two months of internet research. (I was pleased to find that you had also identified this as the ideal case, when I found your site sometime later, but it is a dreadful shame that Zalman have discontinued it.)

 

It has an Asus P5E-VM(HDMI) motherboard with an Intel Core Duo 3 GHz processor, and 2 modules of 1GB RAM.

 

The motherboard was chosen for two reasons. Firstly it was one specified in an advertised ready built PC using this case, so I knew it would fit – as you know, it is vital that the motherboard layout is compatible with the heat pipes in the case, but the published compatibility lists are woefully out of date. It was also vital to ensure that the processor did not run too hot, and so the processor spec was copied in the same way. There was no point in installing more than 2GB of RAM as I am using the 32 bit version of Vista.

 

Vista was chosen - rightly or wrongly - to make sure that Blu-Ray playback would be well handled. I had no knowledge at the time of Vista’s different implementation of audio.

 

The other reason for choosing the motherboard was that it has a coaxial spdif output on the back panel.

I had it in my mind that taking the audio straight off the board to the DAC ought to be ideal (but now of course I’m not so sure). With the previous, noisy, HTPC I had been using a Scott Nixon tubed USB DAC. From reading around on the web, I had my doubts about the quality of a USB feed, especially about jitter issues, and wanted to change to the Cyrus DAC anyway, which does not have a USB input. I have to say that switching to all-Cyrus was a huge step up, but as changing the DAC was part of a wholesale simultaneous upgrade, I can’t say how much of the improvement rested specifically on the DAC.

 

Wrapping up the hardware spec, it also has a Sony BD-ROM, and internally a NVidia GeForce 8500GT video card (to de-stress the motherboard when playing HD video) and a Compro Videomate TV card removed from the previous HTPC. Finally there is a 64GB SSD, which just carries the OS, programs and any caching required. All content is held on the NAS. I never managed to implement the remote control option.

 

So unless the optical drive is running, there are no moving parts and it is indeed absolutely silent. That in itself was a fantastic improvement on attempts to get silent fan cooling – an exercise in futility if there ever was.

 

I will give the detailed configuration of the PC later, but it is an integral part of the A/V and Hi-Fi set up. Its duties are to deliver an audio stream to the DAC in the Hi-Fi, controlled by Media Monkey, play Blu-Ray disks on its BD-ROM drive, play video, mainly DVD, streamed from the NAS, handle free-to-air TV reception using the TV card, allow web surfing using a wireless keyboard with integrated trackball, and deliver video to the LCD panel for all of the above from the video card.

 

When delivering music playback, the only function running apart from Media Monkey may be Internet Explorer, so I can listen while surfing forums such as this one. Necessarily for its usage it has an antivirus program running at all times (ESET NOD32).

 

On the other side of the PC I have an all Cyrus stereo hi-fi, a pair of big Dynaudio speakers, high quality cables and a 46” LCD screen. My primary interest is audio, but it is convenient to integrate TV and disk playback with the audio system. It sounds a lot better too! More than 99% of music listening is from the PC. I hardly ever play cds.

 

I think it is reasonable to say that the stream of content from the NAS up to the ethernet cable socket on the PC is fine, and that from the coaxial spdif feed into the Cyrus DAC XP, the audio reproduction is fine too.

 

My concern is about what is happening between the ethernet port into the PC and the coax spdif port out of it.

 

Almost all of the time the music sounds very good indeed, as it should. However, there are occasional popping sounds, normally not very loud, which I imagine are what I have read about being called ‘artefacts’. These do not necessarily occur at high output points in the music, and are relatively infrequent. Even in quiet sections they sound a little like very brief clipping. They are however frequent enough for me to find myself listening out for them instead of just listening to the music. For reasons I cannot fathom they seem to occur rather more in classical music than in jazz or rock.

 

All the music is album replay gain adjusted by Media Monkey. No normalising is used. The pops seem to occur in consistent positions. I have frequently opened the FLAC files in Audacity but apart from a few exceptions, there is absolutely no perturbation in the wave form where these pops occur. I therefore conclude that they are being generated during processing within the PC.

 

The exceptions were far louder and nastier pops than the others, and were very obviously present in the waveform. I am confident that they were caused by faults on the original cd and/or interference from other processing going on when they were being ripped, and are a completely unrelated phenomenon. I now only rip (on a different PC) when there are no other processes running, since when this minor problem has virtually disappeared. These faults were also easily fixed in Audacity.

 

Apart from this issue of perceived artefacts, there is a second, more objective and describable problem. The Cyrus DAC XP can handle up to 192 kHz streams, and has a display which will show the actual frequency of the stream being played. That works fine, as evidenced by it showing the correct frequencies when playing back a cd or a dvd from a separate dvd player. However, all audio streams from the PC display on the DAC as 96 kHz.

 

This means that the PC is upsampling the stream, because almost all my music comes from cds so it should show 44.1 kHz. Since I want of course a bit perfect delivery to the DAC, this is really unsatisfactory. I think it is clear that this is due to a setting in Vista’s audio configuration, and it is rather obvious which setting that is, but I am still not sure why Vista does it, or how to overcome it.

 

So after that very long introduction, let me give a detailed description of the software configuration.

 

Windows audio settings

 

Digital Audio Device (SPDIF) selected in Sound menu in Settings. No system sound scheme, of course. No other devices connected.

 

In Properties of Digital Audio Device, controller is High Definition Audio Device (Microsoft). The driver is 6.0.6000.16386. Realtek is not installed.

 

Under 'Supported Formats' DTS Audio and Dolby Digital are unchecked, but Microsoft WMA Pro Audio is checked. All the possible sample rates are checked. Volume is set to maximum and all enhancements are disabled.

 

Under the advanced tab the default format is set to 24 bit 96kHz, and both "Allow applications to take exclusive control of this device" and "Give exclusive mode applications priority" are checked. I'm sure this is why Vista is upsampling, but I do not understand why it needs to default to 96kHz when only a 44.1kHz stream is being outputted.

 

That seems to be all the Vista settings.

 

In Media Monkey, I am using the wave Out dll. The volume control is disabled. Buffer length is set to 2000ms, which seems to give effective gapless playback.

 

There is no WASAPI plug-in yet for Media Monkey, which is really frustrating, because a true exclusive mode implementation in Vista ought to be the answer to my prayers. There is one being developed for Winamp, which means it will probably work for MM too, but judging from the thread in the Winamp site under the developer forum, it is still barely at beta stage. Media Monkey developers say this is not high on their priority list as it would only apply to users running Vista.

 

I tried the ASIO and similar plug-ins in the past when running XP and they always crashed MM. I have no confidence at all that they will function at all under Vista, and indeed as Vista has a new architecture, they should be irrelevant to Vista.

 

Comments from other computer audiophiles on all these issues, but especially how to make Vista work well for us, will all be very welcome.

 

Some questions and thoughts I do have are below:

 

Would taking a USB stream from the PC actually bypass this oversampling? Should I use a USB to spdif converter between PC and DAC? On the other hand, could it pass any frequency above 48 kHz?

 

Should I give up and switch to a Transporter, thus bypassing the PC? But in that case what about the interface for selecting music? Presumably that would make it impossible to use the excellent and very flexible Media Monkey interface?

 

Do I have no choice but to use an external sound card? If so which one, as a Lynx attached to a squid-like break out cable does not appeal at all?

 

Questions questions questions ……

 

[PeterSt]

... Your post really is quite longish. Now let's see ...

 

When delivering music playback, the only function running apart from Media Monkey may be Internet Explorer, so I can listen while surfing forums such as this one. Necessarily for its usage it has an antivirus program running at all times (ESET NOD32).

 

IE is ok, but the virus scanner is not. Switch it off and retry. Btw, I never had a virus scanner running on any of my PC's, but then I kind of know what I'm doing.

 

Under the advanced tab the default format is set to 24 bit 96kHz

 

This is just that one and single reason you see the 96KHz output. Set that to 48 or whatever, and you'll see 48KHz output. This is just how it works in Vista and you'll have to swallow it.

WASAPI Exclusive Mode avoids it.

 

Your post is so long that I won't try to find back how you connect to the DAC, but might it be SPDIF and do you have the choice for USB, just try that to judge whether the clicks etc. are still there.

 

A general remark : If you indeed had louder plops and all caused by ripping, you must be very careful at what you are doing, because if things go that wrong at that stage and that faulty (!) already, what about the rest. Of course I am not saying that you are careless, but these things are way out really. :-)

 

Right, so we can't come up with Foobar. Ok ok ...

What you might do just to exclude software issues, is give XXHighEnd (whoooops:-) a download. You might try Engine#3 which is WASAPI Exclusive, or #1 which is Direct Sound.

I have written this all myself,and if you are able to let emerge even one click from it even during massive disk copies etc. (I'm referring to #3 now merely) ... well, you'd be the first. In other words, if you manage to do that I 1000% percent can guarantee it is a hardware issue (or mobo driver etc.).

One way or the other, it will give you the confidence. And then throw out XXHighEnd again.

 

Btw, switch off all wireless too, just for testing. And that includes any IR devices.

 

HTH !

Peter

 

[audioengr]

"Would taking a USB stream from the PC actually bypass this oversampling?"

 

If Vista OS is set for upsampling, then it will upsample as long as you are using the audio stack. Ethernet does not use the audio stack. The thing to do is match the sample rate of the file to the setting in Vista sounds and audio devices.

 

"Should I use a USB to spdif converter between PC and DAC? On the other hand, could it pass any frequency above 48 kHz?"

 

Depends on the converter. My Off-Ramp 3 passes up to 24/96. The Off-Ramp also converts 16/44.1 into 24/44.1, which is still bit-perfect, but automatically bypasses the DSP in Vista. The problem occur in Vista only if you try to play 16/44.1. It does DSP to reduce the volume to about 90%.

 

"Should I give up and switch to a Transporter, thus bypassing the PC? But in that case what about the interface for selecting music? Presumably that would make it impossible to use the excellent and very flexible Media Monkey interface?"

 

True. If you use an Ethernet networked device, then you are usually stuck with the S/W interface/player that comes with it. I am not a fan of Squeezecenter. I like Sonos much better. Networked devices tend to have high jitter, so reclocking is recommended.

 

"Do I have no choice but to use an external sound card? If so which one, as a Lynx attached to a squid-like break out cable does not appeal at all?"

 

The advantage of the Lynx is that it plays all sample-rates and has word-clock input, so it is easily interfaced to a reclocker like my Pace-Car 2. The disadvantage is that you must run it in a desktop or a breakout box, both of which usually have noisy fans and grounded AC plugs. This usually causes a ground-loop. Some reclockers can isolate this.

 

You must decide whether you want wireless or wired. Whether you want 24/96 or not. If you dont care about wires, but you want 24/96 capability, then there are several options:

 

WiFi with Transporter

Async USB with Tascam US-144 or EMU 0404 driving a Pace-Car reclocker

USB interface with Off-Ramp 3 USB converter

 

The cheapest of these is the Off-Ramp 3. Wasapi is not necessary.

 

Steve N.

Empirical Audio

 

 

[Simon Chick]

Thank you both for a lot of very helpful comments. I really should have edited my original post down to something more manageable!

 

The great thing doing a post about a problem like this is that the exercise itself as well as the responses makes one think about the issue in fresh ways.

 

As an initial exercise I have changed the Vista setting to 44.1kHz 16 bit. So far I have not heard a single click, but it's still early days.

 

I had it at 96kHz 24 bit because that is the highest quality out of all the files I have, but it is actually only an infinitesimal proportion of the library. After reviewing my own post and seeing the replies, I wondered if the unnecessary upsampling by Vista was causing the perceived popping. I will post further to report progress and to respond in a better way to the many points made.

 

Thanks again.

 

[PeterSt]

Hi Simon,

 

I sure hope things keep on going without clicks. Now :

 

Although you won't expect it, even when Vista is set to 16/44.1 and the output to Vista's sound engine is 16/44.1 (hence the same), Vista still resamples. It goes up (most likely to 24/96) and back to 16/44.1 again.

So, if indeed your setting as off now helps for the clicks, you must look in the direction of the soundcard/DAC not being able to cope with 24/96. Note that it goes like this :

 

Source (16/44.1 file) -> Vista sound engine -> soundcard -> optional external DAC or otherwise analogue out.

or

Source (16/44.1 file) -> Vista sound engine -> USB -> External DAC.

 

When you are using a soundcard (sorry I didn't look it up again) it is likely that upgrading the soundcard with the latest drivers helps (that is, when you want to output at 96 again). Of important notice is that at using a soundcard (opposed to USB !) the device should show in Vista as an SPDIF device. When it shows as "loudspeakers" I can assure you the drivers are not on par for Vista, or just are XP drivers. This then may cause any sort of problems !

For USB the "loudspeakers" is just normal.

 

Btw, the latter not to confuse with the normal "loudspeakers" implying analogue out (in 99% of cases present on a soundcard).

Oh, "soundcard" can be present on the motherboard just the same.

 

Best,

Peter

 

[Roseval]

Now and then I hear some soft pops in my classical recordings.

They always happen on the same place so are part of the recording (no external cause like anti virus etc).

I re-ripped a couple of them but the pop remains.

I re-ripped them on a different PC but the pop remains.

Maybe these pops are simply in the original recording as a result of analogue (tape) editing (a lot of my CDs are ADD)

 

BTW: Vista can address more than 2 Gb: http://msdn.microsoft.com/en-gb/library/aa366778.aspx

 

DPC Latency Checker http://www.thesycon.com/deu/latency_check.shtml : it may help you to find the cause for interruptions in real-time audio

 

 

[Simon Chick]

Roseval - that is very interesting indeed. It EXACTLY mirrors my own experience.

 

I am now trying to remember which tracks and where in them I noticed the problems. Clearly I need to address this more scientifically.

 

It has not been long enough since I changed the 'preferred' output setting in Vista to tell whether it has actually changed anything. From Peter's comments it sounds like there is no reason why it should unfortunately.

 

If I am not the only person experiencing this issue then I am already obscurely comforted, at least that it was not my imagination.

 

I will try to gather more specifics then post again.

 

Anybody else out there suffering the curse of the classical click?

 

[PeterSt]

I think my initial response was something like "then something must be seriously wrong in the base". Maybe by know this deserves some explanation.

 

Ripping is a kind of art, which can flaw on some subjects, and for now I'll have one examle;

At ripping (and as EAC denotes) you might be reading from a cache a second time. N.b.: A cache is an area of memory the data is read in before it's transferred to wheever it needs to go, and when it is re-needed it is taken from that memory instead of the original source. That is faster. Now :

At ripping, and the (EAC) technique of reading the data several times in order to check its decency (and which is the only means to do it, because the usual error checking is not availble to this process) you can guess what happens if this cache is there, activated. Whatever error may reveil because of re-reading, it won't be there. Right ?

 

So, even ripping software like EAC won't warn you against these errors, and they will be in your rips forever.

The only thing EAC can do for you, is switching off that cache. Why it doesn't by standard is a big guess, but in the end you have to do it by means of a checkbox.

 

I once had, by accident, switched the cache on at using a new drive, which went unnoticed because the new drive should be faster, and it just was. But it was because of the cache, and re-reading is a 1000 times (or more) faster in that case. The effect ? the 40 or so rips I did before I noticed glitches at playback just had glitches ALL of them. Not in all tracks, but always on a few tracks at least.

 

From there on I created "glitch detection" software, in order to learn from it, assuming that many more glitches would be there than I could hear. And I can tell you ... thousands and thousands per album. I may have heard 5 per album ...

 

Even at good ripping, the glitches will stay and they go unnoticed. Yea, scary, right ?

The fun is, re-ripping -again with some experience- may get them good afterall, but it takes (for example) to start the ripping at that particular track. Things are colder, I don't know.

Usually (but not always) re-ripping the complete album gives the exact same results as before.

 

Note that this "glitch detection" shows exactly where and how many faults were perceived, and keep in mind that a stereo 16/44K1 sample contains 44100 samples per second, so a one hour CD is 3,600 times that. When some samples are wrong in that huge pile, and they are on the same place, this is no coincidence. It is just wrong on the CD, never mind it can be read good afterall. So, those samples have not been written wrong, just not the best.

 

Now keep in mind ... a glitch is a stream of bytes which remain of the same value, where they should not.

 

In XXHighend another phenomenon exists : Crack Detection.

Crack Detection works the opposite from glitches, and it detects unnatural dynamics, or IOW, typicle ticks. BUT : A tick consisting of one sample only, is not audible (trust me).

The point here is : this Crack Detection just never fires (unless I did something wrong in the playback software), which tells me that poor ripping just not leads to wild values in the resulting file.

 

All 'n all to my (rather explicit) analysis over time, poor ripping does not lead to ticks, but to glitches only (could be a sustain of a sample value, or nulls -> quietness for a fraction of a second).

Ticks, however, can emerge by poor software or poor drivers (which is also software), or may other influences in the PC that make stall the audio engine and can mangle the byte offset. With this latter I mean that 16/44K1 stereo samples work at four byte boundaries, and when one byte is skipped, you'll have static. When two bytes are skipped, left and right are switched. :-)

Since nobody has static suddenly, bytes just are not skipped, and I don't see how an occasion of a skipped byte resurrects in a properly synchronized fashion again. BUT :

 

Supposed there's a glitch stucking on +1.8V, and this coincidentally turns into a glitch stucking on -1.8V (near the range of a 2V normalized DAC) I suppose you indeed will get a tick. However, while I know the glitches are in many rips, I never perceive ticks. Never.

 

Never ? not completely true. When I use a PCI based soundcard, by means of moving windows over the screen, small vinyl like ticks can be incurred for. But this is unrelated to the source material.

 

2c

Peter

 

[Roseval]

Most of my CDs I ripped to FLAC on a Hifidelio = CDparanoia

I duplicate it on a iMac running Vista Ultimate with error correction on.

The clicks remains.

A more thorough approach would probably be using EAC or dbPoweramp because both support AccurateRip allowing you to compare your rip with others.

The problem of course is that it is classical so the change that your CD is in the AccurateRip database is probably low.

I don’t think this is a Vista related problem

 

 

[Simon Chick]

Well this just gets more and more interesting.

 

I am amazed that I have never before come across any discussion of the phenomenon, which seems to go to the root of successful ripping.

 

I am still posting before properly absorbing the wealth of data being offered.

 

However, why could I not see the glitches in Audacity once magnified to bit level? And indeed why are classical music cds the main culprits?

 

The type of gross click due to interefence from other Windows activities was always very obvious, although fortunately rare (and non-existent now I never multi-task when ripping). As I recall it was normally just one bit spiking out of the waveform. Manually put it back into the curve with the Audacity draw tool, and problem solved.

 

These soft pops do not seem to exist in the waveform, which is why I thought they arose in processing in the PC. However, why they should be in the same place always continues to confuse me.

 

So, one simple question to be going on with - why are these soft pops not visible in the waveform at bit level?

 

[Roseval]

I witness it most of all in chamber music, a few instruments only.

Probably the magnitude is of the same order as thinks like the tapping of a shoe, the squeak of a seat and all those tiny details you can hear with revealing audio equipment but probably won’t see in the waveform.

Maybe if you do a Fourier analyses you can identify the source (don’t ask me how to do this)

There is in general nothing making a continuous broad spectrum noise like bass/drums in pop or jazz so nothing to mask all kind of ‘background’ noises.

 

 

[PeterSt]

So, one simple question to be going on with - why are these soft pops not visible in the waveform at bit level?

 

Let's try ...

 

First compare real memory playback and "normal" playback. The latter reads chunks from disk, usually of the same size always, and if not, with a repeatable pattern from off the start of the file.

The first reads the complete file in one go.

How do both relate, and how do they relate to the story here ?

 

You could generally say that in either case the successive chunks read go into another part of memory. In the case of the memory player you could say this can happen once per track only. Now :

 

I can point you to many months lasting threads on my own forum (dealing with the development of XXHighEnd) where people (sure not all of them) could run into a "click" at the boundaries of two adjacent tracks. I myself could hear it too at some stages, but usually not.

Such a click, evidently occurring because of the chunk read going into memory and some things going wrong, may occur once per day only, and only with very very much luck it was repeatable within one album, the click e.g. occurring between the 5th and th 6th track, then between the 9th and the 10th etc.

 

The point to take here, is that while in my situation such a click only could happen once per track at most, in normal situations where chunks of, say, 5 seconds are being read, chances are much much higher.

 

With much effort I was able to prove that it was not me doing something wrong in the software, but that it "just happened".

At some stage I was able to prove that the Windows swap file gets the most priority, and that it would stall some audio process, a click then occurring when coincidentally the output voltage of the DAC was at some positive maximum, and when sound commenced (think in ms here !) it was at a negative maximum. Not much different from what I explained before, and also not much different from a PCI buss stalling things (moving windows etc.). The point is, in this situation it happens at the same times, and this is at the boundaries of read chunks of data.

 

On a side note (but very important for the technical merits of this) one must know that those chunks of data never can go in the same part of the memory, because a second one would overwrite a first. So, two parts are involved, and they are used like 1-2-1-2-1-2-1 etc.

 

For a Windows machine, and .net for sure, it came aparent to me that the way this memory is under the control of the programmer, actually comes down to "no control at all". Btw, this is official, and .net programming is also referred to as working with "managed code". The "managed" refers to the management of memory, and where the programmer says "throw away because not needed anymore" it is the OS that determines when that really happens.

Normally this goes rather unnoticed, but when working with 700MB files going into memory, you really notice when you think you're uwing two but Windows uses another two old. This is why the swap file became important, to me.

 

Outside of the swap file being involved (it can be shut off) the clicks could still happen, and after a year being bugged with it (imagine, people complaining about hearing one click per day) I decided that there was only solution to this only : outsmart that "managed code". Officially this can't be done, but after quite some (design) attempts I knew how to do it, and with a throughput time of many months I could set the program up side down completely in order to let the tricks work, and when done ... they did.

No click ever since at track boundaries.

 

So ... now you possibly understand better why I in the first post talked about XXHighEnd as the means of proving what the cause is;

a. during the playback of a track this phenomenon just can't be in order (nothing is being read and no swaps of memory *can* take place);

b. I know about all of the efforts it took and just nobody had a single click ever since (and those "naggers" REALLY complain about one click, because highend = highend and clicks don't belong there, unless you're playing vinyl.

 

So, very much explainable, and not even a long shot I think.

As said earlier, I never have clicks, but as you know know, the ones which can just be explained I obviously had. :-)

 

Peter

 

[Simon Chick]

Goodness me, this is getting very complicated, and is maybe going to take a while to approach a conclusion. It is also difficult at present to give proper time to focus on all the issues. Temporary silences on this thread will not mean loss of interest.

 

I think that one simple answer I can take from this is that the pops are being created in the PC. They cannot be seen in the waveform of the file because they are not there.

 

All my ripping is done in EAC with Accuraterip activated. However, having surfed the XXHE forums earlier today, I see that there is little faith even in EAC now.

 

I identified a pop, louder than the norm (at 1.09 on final track of cd25 (de Falla) of Harmonia Mundi anniversary boxed set, in case anybody can reproduce this). The click always occurs at the same spot on my Vista HTPC. Also using Media Monkey but on a different PC, running XP and a different on-board sound driver, the click was identical.

 

BUT opening the file in Audacity then using the Audacity player, NO CLICK, in the same XP PC.

 

This simply confirms I think that these pops are a processing issue. No offense to Peter, but I am not really interested to try XXHE. I'm not that intense about it, I just want to lose the clicks. I am wondering if it is MM and/or flac processing (Audacity converts to its proprietory format I think) and/or the lack of a WASAPI plug-in for MM.

 

If Audacity can play the file without clicks, then other relatively convenient software must also be capable of it. I just don't want to lose the attractive and feature rich MM interface.

 

Meantime I need to lie down in a darkened room for a while.

 

I will think further and study the responses more carefully before posting again. Further comments and shared experiences always appreciated.

 

[PeterSt]

Hey Simon,

 

Because I want to know everything myself (excuse me for it :-) could you please do this :

 

Send that file to me (sales at phasure com) and use this for it : http://www.phasure.com/index.php?topic=721.0 Note this is completely free, although at first it may look like it is not.

 

I will be the most happy to look into that file through my glasses and see whether I can find a reason that most software struggles over it. Of course I will try it with XXHE. And, no problem at all that you rather not use XXHE. That is not the subject here !

 

Btw, did you think of certain software (e.g. AudaCity) just *not* unveiling a tick ? This is not difficult you know ... it is all a matter of better 1:1 reproduction, and I can show you XXHE versions unveiling LP like crackles on some recordings, while other versions do not. Guess which version is the better one ... :-))

 

But please send me that file. For my own sake (and offering better help a next time !).

Thanks,

Peter

 

 

[PeterSt]

Hi Simon,

 

Thanks for sending the file.

 

Around the 1:09 area the file is near clipping (left channel anyway) and at 1:12.99 it really does. Maybe you can see it yourself in AudaCity. Btw, I used WaveLab.

 

No clicks or anything audible though.

 

Explanation :

 

Somewhere in your chain you may (without knowing) apply additional digital volume. This is never allowed btw.

A wrongly working ReplayGain may be an answer also.

 

Another explanation could be your DAC not being able to cope with the rather spikey transients in this area (60dB nearly straight up and down), although I don't know whether that can incur for ticks. Maybe when things overshoot (which is likely).

 

About the content itself ... this has been manipulated somehow. The clipping is soft clipping, and not like (e.g.) JVC XRCD. Actually I have not seen it before.

At the higher amplitudes (which is in the singing after 1:09 towards 1:15), things don't sound good, hence not normal. Kind of oversteered analoguely, then compressed digitally (??).

 

I think it is fair to say that no matter what, your clicks are being caused by the (near) clipping. Why not audible on all players, I don't know, but see above explanations.

 

Sorry I can't do better !

Peter

 

 

Edit : You haven't been using ReplayGain during ripping, have you ? Or applied it otherwise to the file afterwards ?

 

Edit2 : No you haven't, because the log file you added says so. Forgot to look at it.

The clipping I mentioned is not true as such either. But something is limiting clearly.

 

[Grimaldi]

What a very interesting thread. And good to see another CUer

 

[PeterSt]

Simon,

 

I just thought of how to prove what is going on for rough discrimination :

 

So, I say it is no coincidence that you encounter the plops and all at the higher amplitudes. Something in your system can't bear it. However, me saying so is no proof. To prove it, lower the digital volume of the OS a little (the volume of the player -if present- is okay too of course.

 

Does this help ? then I am definitely right.

But in that case something in your DAC is wrong. It should just be able to cope.

 

Does it not help ? then I will continue examining that file. In that case I prefer to have another one for comparing the "plop" environment of both.

 

Btw, when things are near to clipping, it might not be the best to analyze files that start as a FLAC (which is so in your case because you ripped to FLAC). Hard to explain, but an encoder may take some things for granted, and when this is unexpectedly not so, the encoder fails (IOW, the FLAC file would be wrong). So on this matter it is always better to rip the file to WAV, listen whether it is still wrong, and then analyze *that*.

 

Don't think you're burdening me with this ... for me this is only interesting and something to solve. Ok ?

 

Peter

 

PS: But see next post as well.

 

[PeterSt]

At finishing the previous post, I think I may be getting near to a clue ...

 

I think the most "usual" ways of upsampling (something from signal processing theories) require some kind of "ReplayGain", or IOW, the method of upsampling may cause too high digital amplitudes because of the way things are calculated. I can't really comment on this, because I don't do it in such a way (in XXHighEnd) and because of that it just can't happen.

 

Now what if super duper Vista "audio processing" is wrong on this ?

 

For insiders, but for outsiders just the same, this is how things work for 16 bits files :

 

Amplitutes go from -32767 to + 32768, but the "byte" (better : "word") representation in the file is from 0 to 65536.

 

It is rather difficult to deal with this properly, because deep inside (C language programming) it comes to this :

 

32768 + 1 = -32767

or

-32767 - 1 = 32768

 

Note that the numbers are representatives of voltage ...

 

Now, if -at upsampling- amplitudes are recalculated and the program concerned adds resp. subtracts a value to an amplitude which is near clipping (this is near 32768 for the positive voltage and near -32767 for the negative voltage) *and* it does not take into account this awkward behaviour of C programming, then you'll have a voltage jump from maximum to minimum and back. "And back" because supposing we're at the positive side of the voltage (think of a sine) and we jump all the way to the negative side because of a bug, the next (or a few later) sample we go back to were we belong : the positive side.

This is audible for any DAC.

 

It is obvious that I took into account this behaviour, and there was some time I did not.

 

I think even without upsampling this can happen, as long as we're dealing with a not bit perfect process. For example, the dithered bit XP applies even without any resampling, may just cause this to happen, if only the native source has amplitudes at the very maximum.

 

Of course, when the OS is doing this to you *after* the player, there is nothing to do about it.

 

And I may even wonder ... wasn't it so that WMP (I talk XP here) has a maximum digital volume of 99% ? ... one may wonder why that is ...

 

This too can be proven by lowering the digital volume (the slightest lowering will be enough).

 

And of course you already *have* proven that it is in the area of re-/upsampling (in Vista anyway) because it doesn't happen at 16/44.1 output ...

 

Where can I put my money for bets ?

 

[Simon Chick]

Peter, thank you very much indeed for giving this issue so much thought. (And Hi to Grimaldi. We get everywhere don't we ;-})

 

Inspired by the comments in Peter's earlier post, since getting the sample file, I unchecked "Level Playback Volume" and "Clipping Prevention" in the options menu of MM.

 

Voila. No click any more on that track.

 

So I think this is final confirmation that the pops were coming from processing, not the file, and it's something of a smoking gun for MM.

 

I will keep listening though, to see if any other music still has pops.

 

EDIT I forgot to mention, switching to the 44.1/16 bit setting in Vista did not actually solve the issue, as you predicted.

 

The downside is that now I no longer have gain levelling. Switching from the Ting Tings to Chopin is going to require care! At least almost all of my listening is album based, not random.

 

FYI, I convert to flac as part of the EAC rip process. I did see the rather uncomfortable levels near the end of the file when I opened it in Audacity, but assumed they simply reflect the level on the original cd.

 

Replay Gain is applied in MM afterwards on an album basis. The analysis just adds a track and album level in the tag. I am fairly confident that it does nothing to the file itself.

 

I believe that if playback volume levelling is unchecked then MM simply ignores the Replay Gain values in the tag.

 

I don't think there is any issue with the DAC (as Grimaldi will understand, this must be an article of faith).

 

So now the question is: Can this undesirable side effect of Replay Gain be solved, and is it a factor of my particular setup, or a common issue?

 

I wonder if this will help Roseval too?

 

[Simon Chick]

I found a list of other click points on tracks (all classical) I had written down a couple of months back. Now none of them have audible clicks, at least when replayed using MM on the XP PC. I can't get to the big system and the Vista PC until my wife stops watching TV!

 

Also, I have re-enabled "Clipping Prevention" in MM, apparently without ill-effect. A lot of rock music tends to clip if not gain adjusted, at least it did when I used mp3s in the distant past. So I felt this was still desirable so long as it does not re-introduce clicks.

 

[Grimaldi]

Hi Simon and everyone else,

 

Just wondering if the classical tracks that you mentioned are all characterised by having a lot of quiet passages on the album or track in question (as can be more the case with classical music compared to rock/pop/etc), thus if MM is trying to calculate the replay gain volume increase or decrease its thinking that the track is on average "very low volume" and thus increases the gain, not appreciating the dynamic differences that are supposed to be there which ultimately leads to clipping?

 

I've never had such probs with my DAC-XP but then I don't typically listen to classical and don't adjust the gain in any way. I could try one of you problem tracks on my DAC-XP but at the moment all my streaming is through iTunes and AE as the PC with a digital out is in another room from the hifi.

 

My worry would also be that MM has to be changing the wave form when adjusting the replay gain and thus is doing additional processing to your lossless files. The ideal solution would be something that sent a message/signal to the preamp to adjust the volume in that way.

 

Just some thoughts

 

 

 

 

 

[PeterSt]

Hi Grimaldi,

 

You are of course exactly right in thinking that MM may (or will) adjust more to the precious file than we might know. But then I would (like you) never mangle with gain in the first place. The MM case however, seems to be explicitly wrong. Also one may wonder what "prevent from clipping" means, and why it is there in the first place (and add to that it doesn't help a bit hahaha).

 

Also, I guess it is now proven that this is not caused by the DAC. So don't worry about that anymore.

 

To be clear on another thing : digital clipping by itself is harmless, although it molests sound. The only thing happening is that a nice amplitude which wanted to rise some more, is suddenly cut. A sine because square of it (think about the top of the sine being flattened), and things start to sound rough. It will not create pops and clicks or anything.

But :

Think about my example on the 32768 etc.; in the, say, "calculation domain" things can go wrong, and while 32768 is the maximum value nothing prevents the faulty programmer to ad another 1 or 5 or 100, and either jumps to negative as explained. This *is* virtually about clipping, and about having higher digital values opposed to allowed. But this is ALWAYS about wrong programming ... which ... can already happen at the A/D process and thus indeed can be in the file (or on the CD) right from the beginning.

 

But I never noticed such a thing.

 

Peter

 

 

PS: Simon, very glad of course that this issue is out of your way !

 

[Simon Chick]

Your comment about clipping prevention is well made, so I turned it off again.

 

I have just spent time listening to rock music with the highest recording levels I could find, right up to Iggy doing Raw Power, which has a calculated album gain level a jaw dropping 16db over the target level of 89db.

 

No audible clipping, so I will now leave that item unchecked permanently.

 

I think the clipping prevention must be some sort of mp3 related thing. I remember years back when I first started investigation of playing digital files through the hifi, I nearly gave up because a lot of the files distorted horribly. Then I found mp3gain, and that issue was solved.

 

However, I gave up on mp3 ages ago, but kept the belief that gain control was still necessary. It seems it wasn't.

 

I am however going to look at alternative streaming options now, to bypass the PC completely.

 

Thanks again to all especially Peter, for the time spent helping me.