Bug Head Player

@Nikhil, it's good to see your missionary zeal:)

But there's no real need to defend the Bug Head - it sings too clearly and so sweetly that it speaks for itself. All the shortcomings in terms of UI, usability, high demand on resources, etc are now well-known and well-documented on this very thread. But in its defence, other hard core audio players also make stringent demands on hardware and optimisation at the cost of usability. For example, some players supposedly sound best when run on two (or more) computers. Most players do well when other, less needed processes are shut down forcibly. Some go to extreme mode like Core mode in Windows server, where one loses a functionality as basic as Windows Explorer.

People go such lengths for better sound.

For the sceptics, I can only request you to give it a try for yourself. I have given settings which will run on most PCs. So before plonking money to upgrade hardware, you can surely have a taste of what Bug Head has to offer in terms of sonics. If after trying you don't like the sound, then consign it to your bin of "yet another player in a long line of bad players" that had unfortunately come your way. No offence will be taken by those of us who've fallen in love.

The UI weirdness, unfriendly usability, long cue up time, etc are now well known and we've heard enough cribs so please refrain from adding more:)
 
Last edited:
What are you referring to here? How do you know he is using API's? API's for doing what?

BTW, thanks for the link. Nice read!

You are welcome.

When you access any resource from a PC, different languages handle it differently. In most low level languages such as C, you can insert assembly code to execute, for example, the read / write from HDD and memory. Assembly code, if needed, can also bypass the OS and execute it's operations at the kernel level.

In high level languages, this interface is built as an API. These APIs are interfaces between the language and operations that are needed, including I/O. When you start using APIs, you do add one or two additional layers between the language and the operation that you want performed. In most cases such as GUI or even disk read, this will not matter. But in time critical operation, this could make a difference.

What most programmers do is to load a sizable amount of data onto the RAM and process it there. The data that is read has to be compared to something for accuracy. In regular computer data, simple checksum and other error correction techniques are used. In audio, the rules are different.

EAC, for example. reads from the disc and uses multiple databases to decide for itself whether the data is accurate or not. It uses a CD ROM offset to understand what possible errors could occur. If reads a block of data multiple times to see if the CDROM returns the same value every time. If the data is different, it start implementing it's offset logic, and starts re-reading the block again. This iteration is done as many times as needed till EAC feels the data it receives is good enough.

If connected to the Net, EAC uses a large online database to compare the data with previous reads of the same CD. At the end, it approximates the accuracy percentage and tells you how reliable the read is.

In DSP when you are working with discrete computer data, it does not make too much difference. But, in audio and video, where the original signal is analogue, DSP of the digital version becomes tougher. That is why there are so many arguments as to why one DAC is better than another, or one player is better than another. Ultimately it is a question of how you process the data and the logic you use to convert a digital curve to an analogue one.

When the ADCed data is sparse, it becomes difficult and 'subjective' to decide as to how to process the data. That is one of the main reasons why modern ADCs are looking at higher bandwidth and word length. Essentially they are creating more data in the ADC process, so you have to do less work in recreating the analogue curve. It is as simple as that.

Cheers
 
Venkat, I understand all that but that still has not answered my question. I think you were presumptuous when you said he used API's. You probably don't know if he did and I don't know if he didn't. PureBasic also allows ASM code to be embedded - that's why it's so powerful. It doesn't get any more low level than that.
 
I am not presumptuous. That is a strong word. I am assuming he is using APIs extensively as most programmers do. I could be wrong.

Cheers
 
Last edited:
Hi,

He is back. 6.48 released.

Regards
Rajiv

Yes he is. Just downloaded 6.48 but noticed that 6.45 does not have an uninstall option.
Went ahead with the Check for Updates on the Bughead Start Menu.

Will post impressions after listening later on today.
 
I am not presumptuous. That is a strong word. I am assuming he is using APIs extensively as most programmers do. I could be wrong.

Cheers
My apologies! I didn't mean to write presumptuous and I really don't understand why I used that word. What I wanted to day was that you are presuming or assuming in this case which is unfair. Again, sorry for the unintended offence (if you took any).
 
Last edited by a moderator:
On another note, being forced to use Normal mode by version 6.40 being such a resource hog, I'm developing a liking for Normal;) It seems Normal is a bit more hard hitting and x4 seems more mellow. I never gave Normal a real listen, and now that I have, it definitely has its merits.

Josh,

I had read that the developer himself recommended using Normal mode.
This was around the time he had released 6.31 or maybe earlier to that.

Having never really tried the others extensively I really never did a comparison.
Normal mode is excellent on my setup - vocals being my favorite genre.
Currently listening to Japanese singer Emi Fujita and the sound is exquisite.

Regards.
 
Yes he is. Just downloaded 6.48 but noticed that 6.45 does not have an uninstall option.
Went ahead with the Check for Updates on the Bughead Start Menu.

Will post impressions after listening later on today.

Nikhil, dont have to uninstall bughead, with the new installation, it removes older version automatically and same happens with rewrite setup.
 
Nikhil..can u please elaborate your current pc configurations.

My audio machine configuration:

Asus Gigabit B85M-G motherboard
Intel Core i5 - 4440 CPU @ 3.10GHz
Transcend 8GB DDR3 1600MHz x 4
Kingston 128GB SSD (mainly due to local availability)
OS is Win7 64 bit

This was based on what was available locally a few months ago.

Hope this helps.
 
Nikhil, dont have to uninstall bughead, with the new installation, it removes older version automatically and same happens with rewrite setup.

Thanks dheerajin. Ended up doing exactly that.
As a habit I prefer to do a clean uninstall and then install the new version fresh.

Regards.
 
My audio machine configuration:

Asus Gigabit B85M-G motherboard
Intel Core i5 - 4440 CPU @ 3.10GHz
Transcend 8GB DDR3 1600MHz x 4
Kingston 128GB SSD (mainly due to local availability)
OS is Win7 64 bit

This was based on what was available locally a few months ago.

Hope this helps.

Great.Are you running infinity blade or bug head.Do you know how to use the Oculus ?
 
Great.Are you running infinity blade or bug head.Do you know how to use the Oculus ?

Infinity Blade mostly.

The Oculus to my knowledge is a future yet to be announced feature.
I might not be up to date but that was the last I read about it on the JPlay forum.
 
I've put 6.48 through the paces and it seems to do very well in the midrange, female vocals sounding very good. But the highs sound in a way recessed, producing an unusually deep sense of depth, as if the main artist fronting the band is a bit too far from the rest of the ensemble. In my setup it causes a sense of disconnect on some tracks, almost like there is phasing.

Also the bass is much lesser than 6.45. As is the overall level.

My usual tuning (Normal > Star tuning > 3) with avx boost plus mistake - just doesn't cut it on this version. Normal > Galaxy > 30 with mmx+ boost plus mistake works much better on this version.

But on tracks having lots of high frequency percussion, this version sounds very, very beautiful. Turn up the volume slightly higher than usual and soak up the purity of triangles, assorted bells, cymbals, etc.

I guess this version is not a keeper at least for me. Hope the next version suits my taste more:)

As always, YMMV.
 
I didn't like 6.48 as it seemed to sound a little muddled.
In my setup there was a little bloat to the bass as well.
Josh has expressed it better than I could have.

Have reverted back to 6.45 - sounds much better to me.
 
One of the earlier versions talk about burn-in

[5.24] NEED Additional BURN IN 400+ hours
at this site
Bug head

Is there some ML algorithm at work here? Is this what the developer means by burn-in?

Thanks,
Raghu
 
Yes he does talk of burn in but nobody knows where he gets that from.
At the rate he has been releasing updates there is no chance of 40 hrs let alone 400 hrs.

His approach is unique in that he developed tools like "ReadWrite Data" to defragment the player and driver files before playback. This I read addresses deterministic jitter. I've never seen any software developer think in this direction before. In any case he states up front that he has no scientific basis of his approach - only the sound.

Regards.
 
Jitter is not entirely deterministic.
To draw a parallel in today's high speed networks (which I am familiar with), jitter is akin to micro-bursts.
This phenomenon exists and alters normal behavior without leaving a trace.
To tackle something that is intrinsically indeterminate, one would need to interpolate sufficient samples of data and possibly apply ML algos on them.
The accuracy of the algos (for convergence) depends on sample size and complex matrix operations in real time.
This may explain the requirement of large amounts of RAM.
Cheers,
Raghu
 
Wharfedale Linton Heritage Speakers in Red Mahogany finish at a Special Offer Price. BUY now before the price increase.
Back
Top