Advanced ABXNo currently available ABX application is able to switch without audible transients between tracks. The resulting clicks and pops can both increase the number of false positive and false negative results. The former happens, when the type of clicking correlates to the type of switch: A/A or A/B. False negatives become more probable, when loud clicks desensitize your hearing or keep you from turning up the volume to more revealing listening levels.
Advanced ABX provides transient-free switching!Other exclusive features:- Impedes "fishing" for good results by design by enforcing a chosen number of rounds.
- Customizable transition length to adapt to different material, for example in- and out-of-phase audio data.
- Easily extendable transition mechanism: A very simple API allows scientists and developers to drop-in their own custom transition modules, for example to allow completely seamless switching.
Non-exclusive features:- Computation of statistical significance (p-value), also known as "probability of guessing".
- Multi-threaded, low resource consumption.
- Cross platform Java binary. Custom Windows and Mac executables.
- Nice and simplistic GUI.
- Textual output for easy publication of results.
Screenshot:(http://www.uebber.de/advabx.png)
Notes:I could only test on a Mac, yet, where it works flawlessly. Please report wether it also works on other platforms. Input is currently WAV only, and the files must have identical format and length. The program is basically able to work with all PCM integer bit depths up to 32 bit, but in practice one is limited by ones specific JRE's capabilities. Java on the Mac, for example, is limited to 16 bit. High sample rates should not be a problem anywhere. The back-end already supports looping, it just isn't implemented in the GUI code, yet.
The source code is going to be released later on. Please don't drown me in feature requests, actual code submits are much preferred.
Download:Go [a href='index.php?showtopic=80672']here[/a].
I'm not ABX fan, but downloaded file and tried it:
- works on windows too, and yeah it's small java app
- files needs to be prepared (in wav as said) and placed in Documents folder on Windows (which is opened by default regardless previous choice), no drag & drop and similar noob fantasies
- slider doesn't react when in play mode
+ no clicks and pops on switch with default settings, which is the main purpose of this program I guess, thou fade effect is audible but it beats nice click and pop elimination IMO
BTW, foobar2000 approach (A B X Y tracks) makes ABXing quite easier for me.
Please don't drown me in feature requests, actual code submits are much preferred.
BTW, foobar2000 approach (A B X Y tracks) makes ABXing quite easier for me.
Adding one more button isn't that much of a deal, no prob
Personally I have never used the Y button. If others agree that this should be added, I can do that.
I have added the source code [a href='index.php?showtopic=80672']here[/a].
Developers, who would like to contribute, should check out their sources directly from the repository (http://code.google.com/p/advancedabx/source/checkout). The back-end is plain Java, the GUI is realized using IntelliJ IDEA's XML based GUI designer for Java. Grab a copy (http://www.jetbrains.org/) if you want to work with that.
It would be nice, if someone could add transparent decoding of lossy formats. The SwitchableArrayClip back-end accepts AudioInputStreams and byte arrays as input data. That's what your code would have to provide, after getting passed a File reference.
I'm not going to implement that myself, because I have other priorities, so you would be free to go. My next focus would be automatic encoder delay correction - employing rpp3po's Synchrotron code - a stage which would kick in right after decoding.
Initial Remarks:
1. "Transition Lenght"
2. Windows executable (XP SP3): Play button shows square icon as per stop button.
2. Windows executable (XP SP3): Play button shows square icon as per stop button.
Same here on Windows XP. Also "play progress marker thing" stops not at the end but about one centimeter to the left of the end point (see screen shot). I can put the marker at the end by repeatedly pressing the play button. When end of file is reached I have to press Stop button to get the marker back to the start point. Hope my description is understandable. :-) Perhaps this is intended behavior.
Fade effect is clearly audible and delayed about one second from the clicking on any Track-button
(http://www.haggmark.nl/ostenh/abx_screen.jpg)
Also "play progress marker thing" stops not at the end but about one centimeter to the left of the end point (see screen shot). I can put the marker at the end by repeatedly pressing the play button. When end of file is reached I have to press Stop button to get the marker back to the start point. Hope my description is understandable. :-) Perhaps this is intended behavior.
I'll have a look at that. It is not intended.
Fade effect is clearly audible and delayed about one second from the clicking on any Track-button
You can control audibility by decreasing the transition length - depending on content. There is no minimum, including 0 ms. After some more experimenting today, I have come to the conclusion to set the default time to something much smaller, like 15 ms. I think for in phase content it could be even lower, since it can still be pop-free. It's up for debate.
About the delay. The application cannot control the size of the output buffers coming after itself in the pipeline. Any data already sent out will be played back by your audio system until the actual switch approaches within the stream. Advanced ABX itself is able to work with sub millisecond delay.
About the playback button issue. That means that the JRE's standard font on Windows XP misses the necessary Unicode symbols. Could I please get additional confirmation from Vista and W7 users? Then I'll decide on how to fix this.
Well, I could let the output buffers never fill above 50% by just not delivering enough data. However, to assure click free playback, I would have to increase CPU utilization (shorter sleep cycles between writes). Sadly the audio API doesn't have NIO features, so it is not possible employ more elegant consumer/producer-style signaling.
About the playback button issue. That means that the JRE's standard font on Windows XP misses the necessary Unicode symbols. Could I please get additional confirmation from Vista and W7 users? Then I'll decide on how to fix this.
The symbols render fine in W7.
WinXP with Eastern language support installed: playback button renders fine.
Fade effect is clearly audible and delayed about one second from the clicking on any Track-button
The fade effect sounds like a fade-out followed by a fade-in. Would it be possible to make a cross-fade, where the fades overlap 100% ?
I agree that the delay between mouse-click and audio switch is too long now.
The fade effect sounds like a fade-out followed by a fade-in. Would it be possible to make a cross-fade, where the fades overlap 100% ?
Yes, that's why the current default module is called OutInFader and not CrossFader. It's the intent of Advanced ABX (AA), that new types of transitions can be added easily. But it's not the intent, that I am going to be the one implementing all those...
Give it a try yourself, if you like. All that needs to be done is the implementation of basically just one method: process() in the Transitioner interface. Everything else, like buffering, threading, and timing is automatically taken care of by AA.
/**
* Instances of <code>Transitioner</code> are able to create a transition between two sequences
* of samples contained in two byte arrays, described by an <code>AudioFormat</code> object.
*/
public interface Transitioner {
/**
* The function reads two sample sequences from <code>active</code> and
* <code>next</code> and writes the result into <code>result</code>
*
* @param active Currently active stream.
* @param next Stream to switch/transition to.
* @param srcOffset Position of the first byte to read.
* @param result Array to write the transition to.
* @param dstOffset Position of the first byte to write.
* @param frameCount Transition length in samples.
* @param format Stream description.
*/
public void process(byte[] active, byte[] next, int srcOffset, byte[] result, int dstOffset,
int frameCount, AudioFormat format);
public String getName();
public String getParameters();
}
Look at OutInFader.java in the source package for a simple example.
I agree that the delay between mouse-click and audio switch is too long now.
My idea of last night, to just starve the output buffers, is working out quite well. I'm going to upload a version with just 50 ms delay shortly.
Does the new output buffer circumvention cause clicks for anyone? The playback thread cycles with the following parameters:
- Sleep 20 ms if the output dataline has at least 50 ms stored at the time of checking.
- When feeding to the output dataline, never let it accumulate more than 50 ms worth of audio.
- Loop.
The new binary you posted doesn't want to start here. The first one worked fine. My system is Windows 7 32 bit with the latest JRE installed.
Edit: There is no error whatsoever, the application simply doesn't start. javaw.exe appears in the process list for 1 - 2 seconds and that's it.
Fixed files are online.
Fade effect is clearly audible and delayed about one second from the clicking on any Track-button
The fade effect sounds like a fade-out followed by a fade-in. Would it be possible to make a cross-fade, where the fades overlap 100% ?
I agree that the delay between mouse-click and audio switch is too long now.
I downloaded the Mac version and hear the delay/pause between switches. Also, why wouldn't you have a repeat loop function versus having to manually stop and restart the samples when they reach the end?
I applaud the development of a cross-platform ABX software testing tool. However, this tool seems not quite ready for serious AB testing. Is there a more mature OS X tool available for doing CODEC tests? Thanks
Cheers
Sean Olive
Audio Musings (http://seanolive.blogspot.com)
I downloaded the Mac version and hear the delay/pause between switches.
The delay you are hearing is adjustable in the field "transition length". It is a fade-out of length 'transition length / 2' followed by a fade into the other track of the same length. Shorter transitions are preferable when the material is in-phase. When you set the transition length to zero, there should not be any delay at all, but a seamless switch. Longer transitions make sense for absolute phase comparisons.
The current, fading transition module is just an example. More sophisticated (in theory completely inaudible) approaches have been discussed here recently. The code is
very easy to extend regarding alternative transitions, but none of the discussion's participants has contributed anything in a while. So basically it seems that I could have spared the time, I have spent on this.
Also, why wouldn't you have a repeat loop function versus having to manually stop and restart the samples when they reach the end?
It just isn't implemented in the GUI, yet. That's the sole reason. The back-end code already includes tested and working looping routines.
You'll probably understand that I have somewhat lost motivation. The response here was, to say at best, very moderate - even though this is HA. The code is a schoolbook example of maintainability and extensibility, very well suited for collaboration. Still there hasn't been
any feedback in that direction. Since I din't start this for altruistic reasons but technical interest, the project will stand idle until it can attract at least some momentum.
I didn't really expect this. Maybe software based ABXing in the field of audio isn't just that important anymore. Or it is just more talked about than actually conducted. Or maybe correlated switching artifacts are just not considered that serious, so that simpler approaches embedded into applications with integrated converters as Foobar are just more convenient for most users.
I didn't really expect this. Maybe software based ABXing in the field of audio isn't just that important anymore. Or it is just more talked about than actually conducted. Or maybe correlated switching artifacts are just not considered that serious, so that simpler approaches embedded into applications with integrated converters as Foobar are just more convenient for most users.
Thanks for the reply. I understand your reasoning for not continuing development, if there is little interest. Perhaps you are right, that the demand to ABX lossy audio CODECS is diminishing as more people are using lossless audio.
I just returned from AES London where most of the focus seemed to be on issues related to of hearing/testing high resolution audio (e.g. 24/96) -- some panelists (e.g. Peter Craven) expressed the idea that current scientific testing (e.g. ABX) methods are too flawed to measure the benefits of 24/96. Here we go again
See: - How Do We Evaluate High Resolution Formats for Digital Audio? (http://www.aes.org/events/128/workshops/?ID=2268W6)
Cheers
Sean Olive
Audio Musings (http://seanolive.blogspot.com)
I didn't really expect this. Maybe software based ABXing in the field of audio isn't just that important anymore.
I'm rather surprised too. This is probably the most ABX-minded forum and there are many users who are experienced coders. Unfortunately I have zero experience in coding so I can only offer my ears.
IMO HA should be able to provide a reliable tool to its members.
Considering the absence of a reliable, multi-platform ABX application, TOS #8 should be suspended until that tool becomes available.[/devilsadvocate]
some panelists (e.g. Peter Craven) expressed the idea that current scientific testing (e.g. ABX) methods are too flawed to measure the benefits of 24/96.
Did they propose any (scientific) alternatives ?
Anyone who claims that ABX isn't scientific doesn't know what science really means. Blind testing is crucial to the practice of the scientific method.
You ask why there is so little attention to this?
What about these?
A) For me, foobar2000 does the job on windows, and abc-hr does it for listening tests
B) abc-hr is java and is multiplatform.
C) The problems you try to solve with your solution may be smaller than the problems you add with it.
D) The "teacher method" is not necessary good to get people interested (Teacher method as in: Here you have one piece, build the rest yourself).
Compare your way to present this project to that of lossywav. Lossywav eventually got multiple implementations and is actively watched and maintained.
Your project failed to get attention because there wasn't anything that much interesting in it. Crossfades may be good for DJing, not necessarily for ABXing. Since this is the main goal of your program, instead of a "maybe nice" feature, it has become similar to announce a drinking based on the bottle it is in, instead of what's inside the bottle.
I didn't really expect this. Maybe software based ABXing in the field of audio isn't just that important anymore. Or it is just more talked about than actually conducted. Or maybe correlated switching artifacts are just not considered that serious, so that simpler approaches embedded into applications with integrated converters as Foobar are just more convenient for most users.
Software ABX is very important, and the existing toos lack needed features. The world didn't beat a path to my web site's door back in Y2K when I put up PCABX for download, either.
Stick with it!
Your project failed to get attention because there wasn't anything that much interesting in it. Crossfades may be good for DJing, not necessarily for ABXing. Since this is the main goal of your program, instead of a "maybe nice" feature, it has become similar to announce a drinking based on the bottle it is in, instead of what's inside the bottle.
I think you may not yet have understood the purpose of this project. A dedicated ABX application can never reach the comfort and convenience of an integrated music player. For example, creating a lossy version of an arbitrary track in your music library and loading both into the ABX comparator is just
four clicks in Foobar. AA neither can nor it is intended to compete with that.
Besides mainstream "which is the best bitrate?"-ABX'ing, there are other types of tests, which were
impossible to conduct with
any of the existing ABX software before AA. This is, for example, the comparison of absolute polarity differences. Absolute polarity, in itself, is generally regarded as unidentifiable by ear. But absolute polarity played back over real world speakers can indeed be heard in some cases. I could successfully verify an old suspicion of mine, that an old 22" bass driver in my basement is indeed quite sensitive to phase. My main speaker set in my living room doesn't share that property. I had to write AA, before I could verify that.
AA includes other features, which I miss in mainstream ABX tools, particularly the enforcement of a fixed number of trials. 1. I have caught myself in the past, not stopping before the numbers looked good. 2. The discussions following posted ABX results with 'biased' trial counts, why a fixed number is preferable, can get tiring to read. The fact, that I have included a forced number of rounds, does not automatically mean that AA is intended the better application for everyone. I would actually applaud to see this feature in Foobar, myself. And if AA can demonstrate, that it is really trivial to implement (less than 15 minutes overall), maybe it can depict an encouragement to adopt the idea for other developers.
C) The problems you try to solve with your solution may be smaller than the problems you add with it.
While I can accept, that the bias towards false positives, that is added, when the representations of transitions aren't decorrelated from their type, doesn't interest you, I do not see how AA "adds problems" in any way. It provides features or improvements, that are unavailable in other software. The price is that you have to prepare two WAV files by hand, and in its current form, have looping not yet available in the GUI. That's about all. The necessity, to think about and set a specific transition length, is a part of AA's "advanced" feature set. It don't consider it a "problem" for a path AA isn't intended to follow, i. e. mainstream dominance.
D) The "teacher method" is not necessary good to get people interested (Teacher method as in: Here you have one piece, build the rest yourself).
So your proposal, when one wants to "collaborate" with others towards a certain goal, go all the way alone first. Else others could get the impression that you are "teacher-tricking" them. Besides not sharing your apparently negative bias towards teachers, I don't really get the point of your implied alternative.
Have you had a look at the source? Way over 95% of the footwork for a complete, convenient ABX application has already been done for you. It may still miss some UI convenience (as remembering the last used directory, etc.) and maybe a few more buttons, but that's about it. According to you my alternative would be doing 99% of the myself, just to anticipate even the least negative feelings someone could have about getting something for free. How about we call that the "anticipated spoiled brat"-method?
Do you get my point? For the tiny last percent of remaining collaboration potential, the required investment to spoil even the strangest feeling, that could be raised, is just not worth it.
This is my perspective: First, in my free time I develop stuff for my own interest. And usually I just develop as far as
I need it. The only aspect, where "other people" come in at this stage, is virtual, respectively manifested in how I modularize my code.
After that I might share my work with a possibly interested audience. Then one of two things can happen. Either I get the possibility to connect with (an)other developer(s) with similar interest and we start collaborating. Or it does not happen, which is fine. And then I move on. Currently, my next interest is comparing high resolution tracks* with a native Mac ABX tool, basically a port of AA to Objective-C. I have gotten less and less satisfied with Java's abilities to handle anything else but 44.1kHz/16 bit on different platforms, and even the latter may suck depending on your setup.
Compare your way to present this project to that of lossywav. Lossywav eventually got multiple implementations and is actively watched and maintained.
That's really like comparing apples to oranges. Behind lossyWAV we have an algorithm with virtually unlimited optimization potential and scientific appeal. AA is basically just a tool with feature completeness already in sight. One may add a couple of automatic decoding filters, maybe automatic track alignment (encoding delay correction) a more complete UI and that's about it.
* Against my beliefs, I think I can pinpoint a significant difference between a recently uploaded synthetic 192kHz sample and its Redbook counterpart. But without a Windows computer in sight of my stereo I cannot verify it formally without better tools right now.
I just returned from AES London where most of the focus seemed to be on issues related to of hearing/testing high resolution audio (e.g. 24/96) -- some panelists (e.g. Peter Craven) expressed the idea that current scientific testing (e.g. ABX) methods are too flawed to measure the benefits of 24/96. Here we go again
See: - How Do We Evaluate High Resolution Formats for Digital Audio? (http://www.aes.org/events/128/workshops/?ID=2268W6)
Cheers
Sean Olive
Audio Musings (http://seanolive.blogspot.com)
Ha, I see Milind Kunchur was on that one....too bad JJ wasn't there too. ;>
And Wieslaw Woszczyk is John Atkinson's go-to academic when JA wants to push the high-rez audibility meme.
Must've been an interesting session.
This is my perspective: First, in my free time I develop stuff for my own interest. And usually I just develop as far as I need it. The only aspect, where "other people" come in at this stage, is virtual, respectively manifested in how I modularize my code.
After that I might share my work with a possibly interested audience. Then one of two things can happen. Either I get the possibility to connect with (an)other developer(s) with similar interest and we start collaborating. Or it does not happen, which is fine. And then I move on.
I developed a mIRC script back in 1998-2000. I started alone, and had other people interested and collaborated on making it better (we developed mirc windows with controls before mirc allowed them natively!). Like everything, when interest was lost (or other better scripts appeared), it faded away.
During 7 years, I've also been the main developer under an open source music composition program. I've worked with many people that liked it, improved on it and sometimes they did even more than what I could even imagine to do. Nowadays, my interests have shifted again.
I've also made the java version of lossywav. Nothing special and always one foot behind the actual lossywav, but hey, I found it interesting at first.
So if you like to code in your free time, and then share it, at least do not expect people to show admiration for no special reason. Like you say, I may not see the benefits of it, but that's the way I see it.
Currently, my next interest is comparing high resolution tracks* with a native Mac ABX tool, basically a port of AA to Objective-C. I have gotten less and less satisfied with Java's abilities to handle anything else but 44.1kHz/16 bit on different platforms, and even the latter may suck depending on your setup.
What a shift of interests... to develop in a platform that is considered "make once, run everywhere", to a "build for Apple, run on Apple" one.. Of course, if you are an Apple guy, let be it, but be prepared to face it: Less people knowing it, and much less people interested in doing it for free.
googlebot,
First I would like to thank you for your work.
You seem to pretty hastily think that no one is interested about the inventions you have made. You released this project only a month ago. Surely a developer may be interested to use your source code when the time is right. That may happen tomorrow, next month, next year... (of course "never" is also possible). I am not a developer, but I had a very busy and exhausting last month and I didn't have any time/inspiration/strength for participating the HA activities.
Personally I don't find the demo application usable for testing lossy encodings because it hasn't a possibility to specify the start and end points. I always isolate one potentional problem passage at a time and ABX it separately. It can be as short as a single cymbal crash or something like that. If the start or end position produces a pop that bothers me I can usually fix that by moving the start or end marker very slightly. The current implementation is more like a switchbox for a speaker test, i.e. you let a track play continuously and switch between the "speaker pairs".
In addition, it doesn't work if the tested audio samples don't have identical durations. Lossy decoders don't always decode the original sample amount. The feature in ABC/HR for Java that can remove silent samples from the beginning works fine for practical purposes. It doesn't matter if one of the tested sample files have a few additional samples in the end.
It would be great if someone would combine your work and the now quite abandoned ABC/HR for Java and keep the development active.
if this thread is going to spread in general ABX thinking, I'll throw that that there is space for mobile (java based) ABX software that can convince me that nero hev2 is different than lossless on my phone while I ride my bicycle
I didn't really expect this. Maybe software based ABXing in the field of audio isn't just that important anymore. Or it is just more talked about than actually conducted. Or maybe correlated switching artifacts are just not considered that serious, so that simpler approaches embedded into applications with integrated converters as Foobar are just more convenient for most users.
Thanks for the reply. I understand your reasoning for not continuing development, if there is little interest. Perhaps you are right, that the demand to ABX lossy audio CODECS is diminishing as more people are using lossless audio.
I just returned from AES London where most of the focus seemed to be on issues related to of hearing/testing high resolution audio (e.g. 24/96) -- some panelists (e.g. Peter Craven) expressed the idea that current scientific testing (e.g. ABX) methods are too flawed to measure the benefits of 24/96. Here we go again
See: - How Do We Evaluate High Resolution Formats for Digital Audio? (http://www.aes.org/events/128/workshops/?ID=2268W6)
Apparently there was a presentation from someone from McGill University that claims reliable detection of 24/192 versus 16/44 using her own orchestral recordings. Unfortunately, there appear to have been a number of differences in the respective signal paths.
I just returned from AES London where most of the focus seemed to be on issues related to of hearing/testing high resolution audio (e.g. 24/96) -- some panelists (e.g. Peter Craven) expressed the idea that current scientific testing (e.g. ABX) methods are too flawed to measure the benefits of 24/96. Here we go again
See: - How Do We Evaluate High Resolution Formats for Digital Audio? (http://www.aes.org/events/128/workshops/?ID=2268W6)
Cheers
Sean Olive
Audio Musings (http://seanolive.blogspot.com)
Ha, I see Milind Kunchur was on that one....too bad JJ wasn't there too. ;>
While he is not as well known, one of the ABX co-developers *was* present for much of these shennanigans, accoding to what he told me last Satruday.
And Wieslaw Woszczyk is John Atkinson's go-to academic when JA wants to push the high-rez audibility meme.
Check out this:
A bit of WW's CV (http://en.wikipedia.org/wiki/Greene_St._Recording)
Must've been an interesting session.
We've been here before, and not just a few times. It is just "all audio compnents have a characteristic sound" all over again. Atkinson is still turning that misapprehension into gold.
Hi googlebot,
just read this thread for the first time. Was away from HA for the last few weeks due to the same reasons as Alex.
Thanks very much for your work! I work in Fraunhofer's audio coding department, and I can tell you that artifact-free switching in a blind test software makes testing much easier. However:
AA is basically just a tool with feature completeness already in sight. One may add a couple of automatic decoding filters, maybe automatic track alignment (encoding delay correction) a more complete UI and that's about it.
Sorry, but that's incorrect. Think of all the things that could go wrong. For example, what if the compared WAV files have differing
- lengths, as mentioned? Solution: take length of shortest file
- offsets? Solution: automatic sample-accurate delay alignment, see Synchrotron (http://www.hydrogenaudio.org/forums/index.php?showtopic=72560)
- sampling rates? Solution: error message, or automatic resampling of lower-sampling-rate files to highest sampling rate in the test (in combination with previous points, quite some work!)
- Bit depths? Solution: increase word length of lower-rate files to highest word length in the test
- Number of channels? Similar solution as above
These and Alex's feature description regarding segmenting and looping (which I strongly support) are only some of the features that would attract interest away from ABC-HR and the foobar plug-in to your software. Here is another thing which hardly anyone talks about on this forum but which I'd like you to consider.
The scientific community has been using the MUSHRA test methodology (http://en.wikipedia.org/wiki/MUSHRA) in the evaluation of audio codecs for years. It's also used for the majority of internal tests at Fraunhofer. I disagree that it's only useful for "intermediate audio quality". I successfully used it for AAC tests between 160 and 256 kbps stereo (for example, with less than 10 listeners, it revealed that a particular codec was not transparent at 256 kbps). Take a look at the screenshot in this thread on the RateIt tool (http://www.hydrogenaudio.org/forums/index.php?showtopic=50991) written by Jean-Marc Valin. Fraunhofer uses a self-made MUSHRA tool for testing (no, sorry, can't share it), which looks very similar to RateIt but has the additional feature of looped playback, with hotkeys for setting loop start and end points for faster changing of loops during playback. Send me a PM if you'd like to know further details. Why don't you consider turning your AA tool into a MUSHRA tool? Artifact-free switching is just as important for MUSHRA as it is for ABX!
I'm not surprised that nobody contributed any code to your project so far. It's much less work asking for improvements than implementing them Same with me: I program for a living during day time, I don't want to continue doing it at night. But if you can use some software engineering support (requirements, planning, GUI design mock-ups, ...), I'd be willing to contribute. Last note: notice how nobody replied to Jean-Marc's RateIt thread! You're not the only one with a good idea but little (initial) support
Best,
Chris
@googlebot
It is going to be very hard to get people to commit to a project that you aren't even committed to! You don't get an instant reaction that you like and you are ready to quit. Even worthwhile projects take time to develop and gain popularity.
@bilbo
I'm not interested in "How to bootstrap an open source community project for dummies" kind of advice. If that had been my goal, I would be sitting here churning out feature request implementations, so that everybody would feel involved and love me. Eventually other altruists would chime in and also show off what they can do.
Sorry, I'm not that type and that hasn't been my goal from the beginning. Many much more rewarding things for my free time come to my mind instantly.
I can only repeat: The main motivation for AA was personal, technical interest (and not becoming an admired project maintainer). I shared it on Hydrogenaudio with the anticipation of professional exchange and collaboration. I don't think I owe anyone any more commitment than what I have already delivered to justify that anticipation posteriorly. And it is really no big deal, when no one finds the time to contribute anything right now. I guess I would have done it anyway.
@all
Admittedly I expected more initial interest for a topic so close to HA's Magna Carta. But I have got the impression now, that I may really just have hit the wrong time. Thank you for the recent feedback. I agree with C.R. Helmrich, that there are plenty more potential features left, that would be worth adding. So maybe AA isn't really 95% done but 50%. Any commits are still welcome! I'm willing to help. The next thing I'm going to focus on is marking/looping. But I can't promise when I will find the time.
@C.R.Helmrich
While MUSHRA is certainly interesting, I'm not planning to implement it right now. For anyone interested in the artifact-free-switching part of AA, it is cleanly encapsulated within the SwichtableArrayClip class (in another thread I have also posted a solution for streams). It might be pretty easy to integrate into your own applications and is both suited for pushing and pulling audio pipelines.
Currently, my next interest is comparing high resolution tracks* with a native Mac ABX tool, basically a port of AA to Objective-C. I have gotten less and less satisfied with Java's abilities to handle anything else but 44.1kHz/16 bit on different platforms, and even the latter may suck depending on your setup.
Now, that would be "something".
All the trouble with ABC/HR Java some years back have made me shy away from Java in mix with audio. A native Mac OS X application on the other hand would score a lot more interest from me...
5 years since I first asked for one -> Seeking ABX software for Mac OS X, any good one out there? (http://www.hydrogenaudio.org/forums/index.php?showtopic=32855)
I have been using this on OS X http://emptymusic.com/software/ABXer.html (http://emptymusic.com/software/ABXer.html)
It's lightweight loads fast plays almost all file formats natvie os x app.