View Full Version : TrueHD is not ALWAYS 100% lossless...only 99.998%
BuccoBruce
5th August 2024, 23:48
At least not in DEE 5.2.1
Granted, it's only 467 samples @ only 5.5262 dB above the noise floor, but lossless should mean lossless, no?
Steps to reproduce:
Feed DEE 5.1/7.1 audio with a "full scale" (no highpass) LFE channel that has 0 dBFS peaks
?
Decode and compare however you choose to
Differences found in compared tracks.
Zero offset detected.
Comparing:
"Q:\-46h.flac"
"Q:\-46h.thd_.flac"
Compared 30846960 samples.
Differences found: 467 values, 4:29.905000 - 6:59.012688, peak: 0.000000 (-138.47 dBFS) at 4:29.905000, 4ch
Channel difference peaks: 0.000000 0.000000 0.000000 (-138.47 dBFS) 0.000000 (-138.47 dBFS) 0.000000 0.000000
File #1 peaks: 0.635144 (-3.94 dBFS) 0.631598 (-3.99 dBFS) 0.789073 (-2.06 dBFS) 1.000000 (0.00 dBFS) 0.394280 (-8.08 dBFS) 0.396389 (-8.04 dBFS)
File #2 peaks: 0.635144 (-3.94 dBFS) 0.631598 (-3.99 dBFS) 0.789073 (-2.06 dBFS) 1.000000 (-0.00 dBFS) 0.394280 (-8.08 dBFS) 0.396389 (-8.04 dBFS)
Detected offset as 0 samples.
Total duration processed: 10:42.645
Time elapsed: 0:15.049
42.70x realtime
I was scratching my head for hours thinking about things to check and coming up with nothing because most of the options you can change (except the one that dithers to 16-bit) only make DRC/metadata/loudness/etc. related changes. Was starting to worry that there was always something that would get changed by DEE, then I tried taking a pre-existing THD source (THX 2010 Broadway), decoding it, and re-encoding - and was relieved to see the output was identical to the source.
https://i.postimg.cc/0zNFKLvz/Screenshot-2024-08-05-162421.png (https://postimg.cc/0zNFKLvz) https://i.postimg.cc/FdQQSDGw/Screenshot-2024-08-05-163037.png (https://postimg.cc/FdQQSDGw) https://i.postimg.cc/JyZfRjmx/Screenshot-2024-08-05-163026.png (https://postimg.cc/JyZfRjmx) https://i.postimg.cc/vgypTDZs/Screenshot-2024-08-05-163114.png (https://postimg.cc/vgypTDZs) https://i.postimg.cc/2bxgZm1B/Screenshot-2024-08-05-163214.png (https://postimg.cc/2bxgZm1B)
The "Mix" pictured in the screenshots is the original LFE + the inverted THD LFE summed together and normalized to 0 dB. It looks like the center channel might have also had some differences but I neglected to check that one since the LFE channel caught my attention.
I have yet to find any other sources where the same artifacts appear. For what it's worth, I've yet to encounter any sample where DTS-HD MAS, or any other lossless codec, doesn't produce bit-identical output***
***Save for the 1024/16 samples prepended and appended to everything that comes out of MAS because of reasons.
There's a chance this is something they have already fixed in a newer version of DEE, but, you know :sly:
If you do have access to a newer version of the encoder and feel like testing this "killer sample" out, send me a PM. AFAIK the only settings that actually affect the audio data are <surround_3db_attenuation> (defaults to ON, I have it off) and <optimize_data_rate> (defaults to off anyways). You can set DRC/DialNorm/etc to whatever you want and it won't change what you get out of the other end from eac3to (ignores DRC by default) or ffmpeg (with -drc_scale 0)
Emulgator
6th August 2024, 00:24
Well, first we abuse the LFE channel: feed non bandwith-limited signal to a LFE encoder, and at 0dBFS.
Then we find a difference, a flipping LSB worth. Then we use normalisation on that (a huge amplification under these circumstances).
Then we analyse that boosted ping to find diracs. To be expected ? A comparison would be to drive a car against a wall, record that and...find it noisy.
Lets see if Dolby revisits that use case.
BuccoBruce
6th August 2024, 01:24
Well, first we abuse the LFE channel: feed non bandwith-limited signal to a LFE encoder, and at 0dBFS.
I didn't create or manipulate this source, just backing something up that only had PCM audio. Every other lossless encoder under the sun will give you what you put into it on the other end...regardless of what channel it's on.
Then we find a difference, a flipping LSB worth. Then we use normalisation on that (a huge amplification under these circumstances).
I normalized it just to visualize it, I made that clear. :thanks:
This isn't format fanboism, a lossless encoder should have zero killer samples, it is supposed to be lossless - I'm just reporting what I found...
Then we analyse that boosted ping to find diracs. To be expected ? A comparison would be to drive a car against a wall, record that and...find it noisy.
Again, the expected behavior for a lossless codec is to give you back exactly what you gave it. I'm not sure what a dirac is, or what purpose the car comparison serves. I'm not feeding full spectrum noise, tone sweeps, or other bizarre "test" samples to the encoder - it's bloody anime.
Lets see if Dolby revisits that use case.
I don't expect them to :rolleyes:
I think you've missed my point entirely and replied solely based on the thread title I chose...
BuccoBruce
6th August 2024, 06:08
Here's a different example of it doing the same thing either across three channels or on the third channel (center, not LFE).
Differences found in compared tracks.
Zero offset detected.
Comparing:
"Q:\E3.33\3.33_00011_MPLS_00002_M2TS_track2_jpn.flac"
"Q:\E3.33\3.33_00011_MPLS_00002_M2TS_track2_jpn.thd"
Compared 305088000 samples.
Differences found: 6800 values, 13:00.342854 - 1:38:20.332583, peak: 0.000000 (-138.47 dBTP) at 13:00.342854, 3ch
Channel difference peaks: 0.000000 (-138.47 dBTP) 0.000000 (-138.47 dBTP) 0.000000 (-138.47 dBTP) 0.000000 (-138.47 dBTP) 0.000000 (-138.47 dBTP) 0.000000 (-138.47 dBTP)
File #1 peaks: 0.998749 (-0.01 dBTP) 0.999664 (-0.00 dBTP) 0.999969 (-0.00 dBTP) 0.973450 (-0.23 dBTP) 0.999969 (-0.00 dBTP) 0.999634 (-0.00 dBTP)
File #2 peaks: 0.998749 (-0.01 dBTP) 0.999664 (-0.00 dBTP) 0.999969 (-0.00 dBTP) 0.973450 (-0.23 dBTP) 0.999969 (-0.00 dBTP) 0.999634 (-0.00 dBTP)
Detected offset as 0 samples.
Total duration processed: 1:45:56.000
Time elapsed: 3:56.332
26.89x realtime
This shouldn't be happening, even if it is at -138.47 dBTP and ultimately an entirely inaudible difference of less than 1/5 second total throughout an entire movie (0.002% total samples).
Doubly (heh) interesting is the fact that it coded anything there at all. The input was 16bit here, while it was actually 24bit input in the OP. Putting this THD file through eac3to doesn't show the usual message about a 2nd pass reducing the bit depth to 16 either:
Original audio track: max 24 bits, average 16 bits, most common 16 bits.
kurkosdr
9th August 2024, 15:25
Whaaat? A proprietary and completely undocumented "lossless" format that nobody can study its inner workings isn't really lossless? This hasn't happened since... well... since MQA.
filler56789
9th August 2024, 22:41
Well, it does appear Dolby Inc. skrewed some things when it created TrueHD as a ""superset"" :rolleyes: of Meridian's "packed PCM" (better known as M.L.P.). The use-case of MLP is «audiophile stuff», whereas the use-case of TrueHD is movies, so they apparently decided to "take some liberties" w.r.t. lossless compression :-|
j7n
10th August 2024, 17:07
With movie soundtracks on an encrypted disc the copy is not supposed to be used for new encodings. So there is not any practical gain from them being strictly lossless. Could this be a minor problem with the open source decoder?
filler56789
12th August 2024, 08:44
TrueHD is not ALWAYS 100% lossless...only 99.998%
Well, only yesterday I remembered that the MLP format has a ""feature"" called ReBit :-/
In summary, ReBit is a set of lossy parts ""surrounded"" (so to speak) by lossless compressed segments :-/
The reasoning for the existence of ReBit was/is the maximum bitrate allowed by the DVD-Forum specifications; but I don't know what would be the reasoning (or excuse) of Dolby for allowing TrueHD to include "lossy islands" in a lossless stream, since Blu-Ray discs are not DVDs. 0_o
kurkosdr
12th August 2024, 16:16
With movie soundtracks on an encrypted disc the copy is not supposed to be used for new encodings. So there is not any practical gain from them being strictly lossless. Could this be a minor problem with the open source decoder?
This doesn't make any sense. Lossless means lossless. You supply a set of LPCM streams (one per channel) to the encoder, the encoder encodes them into a bitstream, and during decoding the decoder gives you back the exact same LPCM streams that were supplied to the encoder. The fact TrueHD doesn't do that means that the decoded LPCM output isn't always the same as the LPCM streams the movie studio supplied to the encoder.
Movie studios market the term "lossless audio" for their Blu-Ray discs, but some movies have the Cinavia watermark added (which is by definition destructive to the original audio), and now we learn that TrueHD isn't lossless either. I guess there is always DTS-HD MA.
j7n
13th August 2024, 03:05
The sound is still overwhelmingly "HD" if it delivers 20..23 bits of resolution. On DVD, the bitrate would only reach high systained values during loud, noisy sections, when the ability to hear lower bits is diminished.
junh1024
13th August 2024, 03:36
There might be some factors.
1. Bitdepth reduction might be on in DEE/DME.
2. The way MLP/THD works the core of THD is stereo (IIRC stereo decoding is mandatory for HDDVD, but not surround) , and all surround is a reconstruction, so may produce low level errors.
Balling
6th January 2025, 10:44
Oh, well. I said it first. I tested on stereo THD though. Anyway, our ffmpeg encoder is always lossless, also see Paul implemented more channels here:
https://github.com/librempeg/librempeg/commit/aa9dd5941f71526f5f165765dc25536a94fa0352
filler56789
8th February 2025, 17:50
Oh, well. I said it first. I tested on stereo THD though. Anyway, our ffmpeg encoder is always lossless, also see Paul implemented more channels here:
https://github.com/librempeg/librempeg/commit/aa9dd5941f71526f5f165765dc25536a94fa0352
Yes, it does seem FFmpeg's MLP encoder has improved A LOT since some years ago.
But the devils still insist on requiring the ANNOYING "-strict -2" switch.
As for "librempeg" — well, nobody will care as long as there are no Windows builds for testing the g0dd@mn thing. ;)
LargerJackaal
27th February 2025, 19:06
I didn't create or manipulate this source, just backing something up that only had PCM audio. Every other lossless encoder under the sun will give you what you put into it on the other end...regardless of what channel it's on.
I normalized it just to visualize it, I made that clear. :thanks:
This isn't format fanboism, a lossless encoder should have zero killer samples, it is supposed to be lossless - I'm just reporting what I found...
Again, the expected behavior for a lossless codec is to give you back exactly what you gave it. I'm not sure what a dirac is, or what purpose the car comparison serves. I'm not feeding full spectrum noise, tone sweeps, or other bizarre "test" samples to the encoder - it's bloody anime.
I don't expect them to :rolleyes:
I think you've missed my point entirely and replied solely based on the thread title I chose...
For lossy It also why I personally use Musepack at 192kbps VBR. Since folk on another site took It personally that to me QAAC wasn't fully transparent even at 256 ~ 320kbps, The abuse I got was beyond awful. Because somehow me saying my Lossy choice was MPC for personal use while public would be Lame MP3 at V2 ~ V0. The same ones even lashed out when I stated the same with Vorbis can't handle noisy music without bit starving causing the wind puff/added noise artifact.
modus-ms325c
27th February 2025, 20:43
For lossy It also why I personally use Musepack at 192kbps VBR. Since folk on another site took It personally that to me QAAC wasn't fully transparent even at 256 ~ 320kbps, The abuse I got was beyond awful. Because somehow me saying my Lossy choice was MPC for personal use while public would be Lame MP3 at V2 ~ V0. The same ones even lashed out when I stated the same with Vorbis can't handle noisy music without bit starving causing the wind puff/added noise artifact.
it's not your fault you went with Musepack instead of QAAC or LAME. it's not an invalid choice!
if anything, you just showed who these hydrogenaud.io snobs really are: a bunch of zealots and cultists (all braindead even!) who take blind listening results as gospel irrespective of any actual facts being thrown at them.
john33
27th February 2025, 21:24
it's not your fault you went with Musepack instead of QAAC or LAME. it's not an invalid choice!
if anything, you just showed who these hydrogenaud.io snobs really are: a bunch of zealots and cultists (all braindead even!) who take blind listening results as gospel irrespective of any actual facts being thrown at them.
I take exception to that! It's complete bollocks!! Blind listening tests are the actual facts, not placebo effects.
modus-ms325c
27th February 2025, 22:39
I take exception to that! It's complete bollocks!! Blind listening tests are the actual facts, not placebo effects.you know it's true
john33
27th February 2025, 22:41
You know you must be an audiophool!!
modus-ms325c
27th February 2025, 22:42
lol
"ABX is the word of god!"
john33
27th February 2025, 22:45
What are you afraid of? If you're so sure, prove it! Except that you won't because you might fail!
modus-ms325c
27th February 2025, 22:48
yeah? say that to deaf people or with otherwise fucked-up ears (hearing disabilities)
john33
27th February 2025, 22:50
You're boring me now! How on earth is that relevant?
modus-ms325c
27th February 2025, 22:57
whoops, no ammo left to "toy" with folks of your caliber, you're all-around as rabid a community as you can very well get.
more to the "point", if your ears are more than capable of spotting even the slightest of audio encoding artifacts at higher bitrates from supposedly-good encoders, you don't need to do intense amounts of ABX or double/triple-blind listening tests, at all. you just need to double-check the encodings against the source, and share your findings to whoever is responsible for the encoders in question, assuming they're still around. stop trying to prove the world that some encoder is better than everything else, that your ears are better than everything else, that you can nitpick more artifacting around a song than anybody else, etc.
GeoffreyA
28th February 2025, 07:27
For lossy It also why I personally use Musepack at 192kbps VBR. Since folk on another site took It personally that to me QAAC wasn't fully transparent even at 256 ~ 320kbps, The abuse I got was beyond awful. Because somehow me saying my Lossy choice was MPC for personal use while public would be Lame MP3 at V2 ~ V0. The same ones even lashed out when I stated the same with Vorbis can't handle noisy music without bit starving causing the wind puff/added noise artifact.
If you're talking about Hydrogenaudio, it is a vitriolic community. I haven't got an account there but have been reading for years because the information on audio-encoding is usually definitive. But it seems difficult to have an actual conversation there: as soon as someone touches on quality without an ABX, they start to pounce on them with that dreaded TOS 8, and, on the whole, the tone of the discourse is unpleasant. In contrast, Doom9 has always been quite welcoming, open, and "human." People can have real conversations here on the video topics they love.
modus-ms325c
28th February 2025, 22:03
If you're talking about Hydrogenaudio, it is a vitriolic community. I haven't got an account there but have been reading for years because the information on audio-encoding is usually definitive. But it seems difficult to have an actual conversation there: as soon as someone touches on quality without an ABX, they start to pounce on them with that dreaded TOS 8, and, on the whole, the tone of the discourse is unpleasant. In contrast, Doom9 has always been quite welcoming, open, and "human." People can have real conversations here on the video topics they love.i mean, just look at the previous posts above you. you saw it all right?
simply mentioning that community at all is all it took for some "rarewaves" crook to come out of the woodworks so as to hound me for NO reason.
TOS8 enforcers and otherwise-"normal"-"users"-but-just-as-adjacent-to-TOS8-obedience bootlickers are just that; fanatic cultist zealots who treat their version of "scientific research" of audio encoding quality as gospel.
john33
28th February 2025, 22:51
Your paranoia and ignorance is breathtaking. I know of "rarewaves" but it has nothing to do with what you are ranting about. At least get your facts right. When you sign up to a Forum, you agree to abide by the Terms of Service. If you don't like them, don't sign up, but if you do, you are in no position to complain if you are called out for breaching them. It's not rocket science although, perhaps for you, it is. You are clearly in complete ignorance of the reasons and objectives for the creation of HA. If you want to expound your unsubstantiated claims regarding audio codecs there are many other places you can do so without fear of complaint, but HA is not one of them.
modus-ms325c
28th February 2025, 23:38
Your paranoia and ignorance is breathtaking.surely i must've obtained both these things in isolation. you never know what plays a part in it, honestly.
(hint: not. me!)
I know of "rarewaves" but it has nothing to do with what you are ranting about.actually, i meant "rarewares" but i'm not changing it.
At least get your facts right.or you could've just corrected me, you know?
When you sign up to a Forum, you agree to abide by the Terms of Service. If you don't like them, don't sign up, but if you do, you are in no position to complain if you are called out for breaching them."abide by the Terms of Service" is what i always try to do, but i'm not talking about your TOS in general, i'm talking about the biggest bottleneck for following your site rules.
that's right, folks, it's TOS8, which by the way demands you read unhinged statements from a fucking thread, filled to the brim with wannabe diktat over mother-fucking listening methods, for christ sake!
add in other such lovely moments along the lines of "massive argumentational infighting", "self-justifications as to why ABX, double-blind listening, or some other pseudo-science methodology must be followed or trusted, followed by (or preceding) a mandate to read additional threads containing such" and "generally unpleasant behavior between self-proclaimed civilized people who, under pressure, non-hesitantly makes endless excuses as to why they're such instead of actual self-improvement" and you demand new users to read it all!? really!?
TOS8 compliance leads to cult-like reverence over audio codec listening results, but especially alternative implementations of well-known codecs such as LAME, QAAC, faac, exhale, aoTuV, and so on and so forth.
TOS8 compliance leads to users choosing only the one that proves to score high in (hand-tracked) objective audio quality metrics, often from such time-consuming and potentially mentally-draining methods like what was demanded in that thread.
TOS8 compliance leads to users sticking with that choice only and locking their minds onto that, everything else be damned; when faced with a differing opinion, they'll simply lose their minds and condemn that opinion entirely.
TOS8 compliance leads to one certain audio codec implementation treated like a non-brainer because the big names demanded so.
TOS8 compliance leads to horrifying, uncivilized, braindead behavior from what is supposed to be a civilized community of audiophiles and listeners, plain and simple.
oh, and uhhhhhhhhhhh, have you ever heard of "malicious compliance"? must've been hard for your community to grasp that concept. must be... uhhhhhhhhhhh...
anyway, let me explain that real quick:
wanna tell your mistreated people to suck it up? they'll not only follow through with it but will go a step further, and by the time they're done they will find a way to fuck you up at any opportunity you give them from your massive fuck-ups.
it's what happened to all those ruthless-abusive-and-borderline-sociopathic Rustaceans that tried to push Rust onto the Linux kernel (though in that case it's a fairly ambiguous situation if "Linux kernel mailing list" lurking is your hobby). you try to follow pathological behavior under the pretense of reaping positive rewards for doing so, only to get met with the exact opposite.
It's not rocket science although, perhaps for you, it is.oh, there it is! "rocket science". just what i need for not only what i described above but your following offensive statement:
You are clearly in complete ignorance of the reasons and objectives for the creation of HA.aww, you sure you want to go with that? sure you wanna guilt-trip me into "seeing your perspective" over what goes into "fostering a community" or something?
If you want to expound your unsubstantiated claims regarding audio codecs there are many other places you can do so without fear of complaint, but HA is not one of them.take a look at my post history then. both in doom9 and on HA, where i go by Lampion. both profiles are not private so you can check for yourself whether or not i ticked all these boxes instead of gaslighting your way out of looking through your favored community's actual issues, TOS compliance or not.
Z2697
1st March 2025, 05:43
it's not your fault you went with Musepack instead of QAAC or LAME. it's not an invalid choice!
if anything, you just showed who these hydrogenaud.io snobs really are: a bunch of zealots and cultists (all braindead even!) who take blind listening results as gospel irrespective of any actual facts being thrown at them.
I wonder what your so called "fact" is more reliable than blind listening?
Blind test is more scientific than blindly calling somthing as "fact".
modus-ms325c
1st March 2025, 05:55
I wonder what your so called "fact" is more reliable than blind listening?
Blind test is more scientific than blindly calling somthing as "fact".blind tests being published to the forums by and large end with an conclusion along the lines of "X codec is overall better than the other ones because X codec implementation does audio quality better than the other implementations and other codecs, even".
this has led users to not only hard-wiring themselves into using said codec implementation period, but also subconsciously developing some sort of mental discipline that anyone who says otherwise about such must be condemned to hell and back.
Z2697
1st March 2025, 05:56
TOS8 compliance leads to cult-like reverence over audio codec listening results, but especially alternative implementations of well-known codecs such as LAME, QAAC, faac, exhale, aoTuV, and so on and so forth.
"Alternative" is an odd word to use here.
LAME is one of the first open-source high quality MP3 encoder.
QAAC is a frontend for Apple's QuickTime AAC.
faac is a low quality aac encoder that I hardly can believe has its own "cult".
exhale is the first (and only, for now, probably) open-source encoder for USAC / xHE-AAC.
aoTuV, well it may be a little bit alternative, I know very little about it.
modus-ms325c
1st March 2025, 06:25
LAME is one of the first open-source high quality MP3 encoder.starting with LAME 3.89. there are whispers of lower audio quality at not-so-lower bitrates (both CBR and otherwise, ~192kbps) when using LAME 3.100 though.
https://hydrogenaud.io/index.php/topic,125216.0.html
likely certain combinations from LAME that cause its much-touted "superior MP3 quality" to be called to question.
no talented person provided an actual fix for this, and no blind listening, double-blind listening, ABX or some other "hand-made" "battle-tested" BS metric that isn't already endorsed by the big-name testers was provided to confirm this, which otherwise would've led everyone to believe that LAME 3.100 quality issues need ironing out and to consider other MP3 alternatives whenever possible. as in, "flock to hmp3 without hesitation because some tester said it provides better quality at XYZ bitrates than current LAME".
QAAC is a frontend for Apple's QuickTime AAC.cool.
faac is a low quality aac encoder that I hardly can believe has its own "cult".correct: no one seems to care about faac that much.
exhale is the first (and only, for now, probably) open-source encoder for USAC / xHE-AAC.it only covers about a quarter of the features that USAC has; for that, dev has adviced against using his own implementation(!!!) and seek officially-licensed and commercially distributed alternatives if end-used wanted more of what that codec has to offer.
in every test that exhale showed up, sometimes Opus would score higher in those tests owing to higher quality encode result than the former did, and this is for certain songs where the latter had the upper hand in quality vs the former, sometimes results were neck-to-neck with each other in other songs as well; conclusion ended with "Opus best" and whole community took it as a sign that that codec is the only one worth using anymore.
aoTuV, well it may be a little bit alternative, I know very little about it.it gained recognition for improving Ogg Vorbis encoding quality in mid-2003 through all of 2004, and only kept improving ever since, finally stopping at mid-2011. much of that modified code has been integrated into the codebase it was originally derived from, meaning Ogg Vorbis in its current state already benefits from such modifications, and aoTuV is still being distributed separately by its developer to this day.
see here for more:
https://ao-yumi.github.io/aotuv_web/
GeoffreyA
1st March 2025, 09:01
I haven't been following LAME's development since switching to AAC, not that there has been much development anyway, but ABX testing would help to demonstrate that there was a regression. However, humans are humans, and just as in science, the tools can be used disingenuously or their negative results swept under the carpet if it conflicts with one's aims. (Look at how string theory is considered mainstream with little to no evidence.)
Blind tests are good, and an objective way to say something about quality. But HA's strict enforcing of TOS 8 has, I think, led to a poverty of discourse; and when there is talk, it's about agreeing with the poster of a test, adding little to the signal-to-noise ratio of the conversation. At least, that's the impression I get.
tebasuna51
1st March 2025, 10:11
Please guys stop these off-topic posts.
The topic is about TrueHD, we can add comments about other lossy codecs but remember the forum rule 4:
4) Be nice to each other and respect the moderator. Profanity and insults will not be tolerated...
And also respect other audio forum like Hydrogenaudio ...
john33
1st March 2025, 10:14
Apologies. I should know better!
GeoffreyA
1st March 2025, 10:36
Please guys stop these off-topic posts.
The topic is about TrueHD, we can add comments about other lossy codecs but remember the forum rule 4:
4) Be nice to each other and respect the moderator. Profanity and insults will not be tolerated...
And also respect other audio forum like Hydrogenaudio ...
Apologies, tebasuna.
SeeMoreDigital
2nd March 2025, 14:08
How about splitting out the off topic posts and replies (from post #14 onwards) and creating yet another new 'lossy audio discussion' thread?
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.