I've tried several ABX applications on my MacBook: the Java version (0.52b) for Mac, Foobar and WinABX while running bootcamp/XP.
They all produce audible artifacts when switching between A & B. For this test I used 2 identical sinewave files.
I'm curious if this problem may be linked to my setup or if it's a known issue that doesn't seem to bother anyone ?
Thanks for your help.
I've tried several ABX applications on my MacBook: the Java version (0.52b) for Mac, Foobar and WinABX while running bootcamp/XP.
They all produce audible artifacts when switching between A & B. For this test I used 2 identical sinewave files.
I'm curious if this problem may be linked to my setup or if it's a known issue that doesn't seem to bother anyone ?
Thanks for your help.
What artifacts?
My usual rule is that artifacts can only be ignored if they are either identical for all kinds of switchovers or truely random, and don't disturb one's concentration.
For example, I can reliably ABX the QSC ABX box with nothing attached to it even if it is on the other side of the room.
The origional ABX box and the commerical sequel with RM-2 relay module would yield only random guessing.
PCABX vould occasionally be dependent on the PC you used.
What artifacts?
When I have some time I'll try to capture the signal with artifacts to illustrate. It's something like a crack, click or pop. It doesn't sound like zipper noise IME.
Since digital cross fading has been around for over 30 years, I'm rather surprised that the ABX applications can't switch without artifacts. Music editing is part of my job so perhaps I'm more sensitive to the artifacts than the average listener.
Can we agree however that artifact free switching between identical signals should be easy to implement (in the digital domain)?
For example, I can reliably ABX the QSC ABX box with nothing attached to it even if it is on the other side of the room.
Was that caused by switching artifacts, or were the A and B paths too different ? Did that change when the inputs were properly terminated ?
Yes, ABX programs click on switch because they stop playing one file and start playing another, and I agree that it is disturbing. I also agree this could be improved. It would be possible to perform a fadeout/fadein/mix of the signals when switching them so that playback was seamless. I have no time for doing this in my software. Maybe you could ask Peter, foobar2000 developer, to improve his ABX component.
When I have some time I'll try to capture the signal with artifacts to illustrate. It's something like a crack, click or pop. It doesn't sound like zipper noise IME.
Since digital cross fading has been around for over 30 years, I'm rather surprised that the ABX applications can't switch without artifacts. Music editing is part of my job so perhaps I'm more sensitive to the artifacts than the average listener.
Can we agree however that artifact free switching between identical signals should be easy to implement (in the digital domain)?
The usual artifact is due to signal chopping. If you cut off a signal at an arbitrary point, a click or other transient will be heard there. If you look at the wavefom that is created, it is chopped off.
If you use a hardware ABX comparator, then the point of switch over may be also modulated by contact bounce. This particular effect is random, because it depends on the signal being chopped, which is always changing.
Possible work-arounds including fading the signal out, which presumes a variable gain control element. Doing this at line level in the analog domain without creating artifacts is an interesting challenge. Doing it for loudspeaker-level signals is even more challenging.
If your signal switch is really fast, then schedule the time of switching to be where the signal crosses the zero line.
For example, I can reliably ABX the QSC ABX box with nothing attached to it even if it is on the other side of the room.
Was that caused by switching artifacts, or were the A and B paths too different ? Did that change when the inputs were properly terminated ?
The QSC ABX box uses electromechanical relays. The mechanical noises they make when they operate allow me to tell which one is doing what.
When we were building relay boxes, we chose relays for switching line levels that operated far more quietly (e.g. reed relays), and we selected the relays we used for switching signals at loudspeaker levels because for one thing they made randomized mechanical sounds when they switched.
Yes, ABX programs click on switch because they stop playing one file and start playing another, and I agree that it is disturbing. I also agree this could be improved
Thank you KikeG, I'm glad you can confirm the issue.
IMO an ABX application that produces artifacts is not transparent, similar to a non sterile medical lab. If one cares about ABX testing (like many here on HA), I think it is not unreasonable to aim for an application that is as transparent as possible (not too difficult in the digital domain).
What is the effect of the switching artifacts on test results? Hard to say since there apparently are no artifact free ABX applications for comparitive testing.
KikeG doesn't have time to work on this. Mac developers don't seem motivated to invest time in an ABX application either (been asking for years).
Let's hope that Peter has time and motivation to fix this problem. I'd gladly help beta testing.
@Kees de Visser: Can you reproduce the artifact with real-life audio, not sine waves?
This is an interesting subject.
To get 100% artifact free track switching, the application would need to employ some kind of low-latency playback scheme and switch streams being sent (with a short crossfade) by itself without interrupting the output.
This isn't very compatible with the way foobar2000 works and fixing it would make the ABX component much more sophisticated than it is now and probably also require a new foobar2000 core version.
However, for now, the default output mode (DirectSound) does short fades by itself, so with default foobar2000 settings, the ABX track switch artifacts aren't very obvious.
This is an interesting subject.
To get 100% artifact free track switching, the application would need to employ some kind of low-latency playback scheme and switch streams being sent (with a short crossfade) by itself without interrupting the output.
That's not needed at all. All you need is a small small deque buffer. A switch causes the last few samples filled (from the left) by stream 1 to be invalidated, replaced with a crossfade between stream 1 & 2, and then stream 2 takes over. Output is pulled continuously from the right side of the buffer.
That's not needed at all. All you need is a small small deque buffer. A switch causes the last few samples filled (from the left) by stream 1 to be invalidated, replaced with a crossfade between stream 1 & 2, and then stream 2 takes over. Output is pulled continuously from the right side of the buffer.
Then you need a low-latency solution to send the data from the right side of the buffer to the audio device, or use an output API where the system pulls the data by itself (DirectSound only on Windows I think).
Why could the current method (whatever it is) not be used with the right side of the buffer as its source? As long as the switch is artifact free I don't see any problems, even with a latency of 200ms, for example.
@Kees de Visser: Can you reproduce the artifact with real-life audio, not sine waves?
The advantage of sine waves is that they are rather constant, so switching effects are rather predictable. With music there will be more masking, so the artifacts will probably be less audible, but should still be there.
Let me try again to illustrate why seamless switching is of fundamental importance for ABX applications.
Switching (e.g. cross-fades) artifacts are likely to be more audible when the (physical) difference between the two signals increases. In theory, correctly switching between identical signals should not produce any artifact. However, switching between nearly-identical signals (as is often the case in ABX testing) will result in artifacts (not necessarily audible).
I haven't closely analyzed how current ABX applications switch, but if we assume it's a 0 ms transition (which it clearly isn't), then the AX or BX switch that produces the largest artifacts can indicate the different file and potentially give a false positive. I don't think there is much risk of false negatives, unless concentration is affected.
The only reliable solution to this problem is probably to insert a short mute (with fade-out/fade-in) during the switch, although that could have an influence as well (any ABX expert that wants to chime in ?).
The only reliable solution to this problem is probably to insert a short mute (with fade-out/fade-in) during the switch, although that could have an influence as well (any ABX expert that wants to chime in ?).
I agree. Something like a 100-ms linear fade-out, followed immediately by a 100-ms linear fade-in of the new playback.
Btw, sorry for off-topicness, but I see
Peter is reading this:
I find the foobar ABX component very helpful, but two small improvements would make it much more useful for me:
- A selection indicator on the progress bar, like in the upper bar on this screenshot (http://www.filebuzz.com/software_screenshot/full/24360-vb_progress_bar_activex__ocx_.jpg)
- a "loop selection" check box! Looping selections makes ABXing high bit rates much easier IMO.
- Edit: Oh, and another thing: Maybe the "hide results" check box should be checked by default? Seeing one's ABX performance "live" can influence some listeners' choice of how many ABX rounds to do, a la "I'll ABX until my probability of lying is below 1%". I was informed once that this is a bad thing to do.
If it's not too much work, could you please add this functionality?
Chris
Here are a wav sample and its waveform of the java ABX application's output (on a MacBook).
I couldn't find an easy way to capture the output of foobar while running XP/Bootcamp. If it can be helpful I'll try again.
For this test I used a 600Hz sine and a 600Hz+5Hz sine mix, just because they sound identical and look very different.
WAV with ABX artifacts (http://www.galaxyclassics.com/public/ABXSwitchingArtifacts.wav)
(http://www.galaxyclassics.com/public/ABXSwitchingArtifacts.png)
The artifacts are identical for L and R channel and are pretty random, which is probably a good thing, although artifact-free switching would be better.
Here are a wav sample and its waveform of the java ABX application's output (on a MacBook).
I couldn't find an easy way to capture the output of foobar while running XP/Bootcamp. If it can be helpful I'll try again.
For this test I used a 600Hz sine and a 600Hz+5Hz sine mix, just because they sound identical and look very different.
WAV with ABX artifacts (http://www.galaxyclassics.com/public/ABXSwitchingArtifacts.wav)
(http://www.galaxyclassics.com/public/ABXSwitchingArtifacts.png)
The artifacts are identical for L and R channel and are pretty random, which is probably a good thing, although artifact-free switching would be better.
What is with the artifacts in the middle of the segments with signals?
Do they continue to appear if you switch less frequently?
What is with the artifacts in the middle of the segments with signals?
Those are switches between identical signals, like from A to A, or A to X and X to A when X=A.
What is with the artifacts in the middle of the segments with signals?
Those are switches between identical signals, like from A to A, or A to X and X to A when X=A.
Thanks for the clarifications.
The transients I see are not IMO acceptable on the grounds that they are *not* simply due to slicing the signal.
Does KikeG's code do the same thing?
For maximum sensitivity, there should be no clicks or pops in the ABX playback. The two signals should be Hann windowed (or some other simple window) together for a total gain=1, moving between the two signals.
This window should be at least 10 milliseconds long, if not 40.
Otherwise you corrupt partial loudness memory, and desensitize the test.
For maximum sensitivity, there should be no clicks or pops in the ABX playback. The two signals should be Hann windowed (or some other simple window) together for a total gain=1, moving between the two signals.
Nitpick question: should the window generally be power complementary, amplitude complementary.. or both?
(EDIT: Obviously the assumption here is power complementary)
Nitpick question: should the window generally be power complementary, amplitude complementary.. or both?
At least for lossy vs lossless tests A and B signals are in-phase. So "amplitude complementary" windowing doesn't change resulting signal's power.
The two signals should be Hann windowed (or some other simple window) together for a total gain=1, moving between the two signals.
Isn't that the dilemma ? Switching from A to A requires a different window (cross-fade) than switching from A to B because the signal correlations are different at the switch position (A to A is always 100%, A to B will be less).
Will a short mute corrupt partial loudness memory ? At least a mute will avoid interaction between the A and B signal.
Think of the extreme case when comparing a signal with its polarity-inverted version (e.g. to test audibility of absolute phase).
Think of the extreme case when comparing a signal with its polarity-inverted version (e.g. to test audibility of absolute phase).
That's not a good example, though - there, the short mute is, of course, unavoidable. (And the mixing ought to be symmetric around the mute.)
On a more general point, won't crossfading (regardless of the window used) always result in a transition where the correlation to A monotonically decreases, while the correlation to B monotonically increases? So why is correlation an issue? Of course there will be interaction between A and B, but I'm not clear how, on a per-critical-band basis, it would ever be damaging.
For maximum sensitivity, there should be no clicks or pops in the ABX playback. The two signals should be Hann windowed (or some other simple window) together for a total gain=1, moving between the two signals.
Nitpick question: should the window generally be power complementary, amplitude complementary.. or both?
(EDIT: Obviously the assumption here is power complementary)
You mean, like a crossfade?
Usually, a very short silent period is added. Helps the listener to have an audible bookmark for the switchover.
AMPLITUDE complimentary. If the two signals are not very close to alike, what are you ABX'ing? AMPLITUDE. NOT POWER. AMPLITUDE.
A silent period can disrupt loudness memory. The lack of it can give some subjects difficulty.
Ergo, that might want to be an option in the software.
So why is correlation an issue?
Suppose we use a linear fade with a -6dB gain at the cross point. Suppose X=A. The switch from X to A will be inaudible since the fade won't change the bitstream. The switch from X to B will not be perfect. How audible this switch is depends on many things like how different the samples are, where the switch is made etc.
Because artifacts can only appear when switching between different files, there is a potential risk for a false positive ("if" the artifacts are audible, that is, but that requires another test).
Think of the extreme case when comparing a signal with its polarity-inverted version (e.g. to test audibility of absolute phase).
That's not a good example, though - there, the short mute is, of course, unavoidable. (And the mixing ought to be symmetric around the mute.)
Well, the example is heading into the right direction. See below.
On a more general point, won't crossfading (regardless of the window used) always result in a transition where the correlation to A monotonically decreases, while the correlation to B monotonically increases? So why is correlation an issue? Of course there will be interaction between A and B, but I'm not clear how, on a per-critical-band basis, it would ever be damaging.
It can be damaging vor very tonal stationary encodings. I had this experience when blind-testing an AAC encoding of the Dolby pitch pipe item (si03 in the MPEG test set). AAC does relatively well at high bit rates, so you try to listen very carefully for the slightest amplitude modulations in the encodings. When cross-fading between the hidden reference and the encoding in the test, such modulations can occur because of partially destructive interference in some of the harmonics. I observed that some inexperienced listeners mistake these artifacts as codec artifacts and grade the affected stimulus (the one to which we fade) down. Sometimes, that's actually the hidden reference.
Don't know what's best for such an item, cross-fade or fade-out/fade-in. And that one particular test sample is the only one I know of where cross-fade modulations are a big issue.
Chris