Badaboom 1.1 Preview

Elemental was nice enough to get us a preview build of Badaboom 1.1, due out in the next week or so.

The 1.1 release is pretty significant, arguably just as significant as 1.0 given the list of improvements:

This version offers additional input files, including DivX, Xvid, VC-1, and MKV. The file formats in 1.0 are still supported.

- H.264 Main profile output.
- 1920x1080 (1080p) output.
- New output profiles: Blackberry Bold, YouTube, and Zune.
- Multi-GPU capability: Badaboom can now let you select which CUDA-enabled GPU to run the transcoding on in the Advanced options. You can open multiple Badaboom applications and run different video files simultaneously on different GPUs, seeing similar high performance as you see with running Badaboom now. For example, two NVIDIA GPUs can transcode two movies in the time it would take Badaboom 1.0 to transcode one. For this initial version, there are a couple caveats:

1. SLI must be disabled (if it is enabled) .
2. Each GPU needs to be connected to a display.
3. Each GPU must have a desktop enabled on it.

I’m not particularly interested in the multi-GPU support that 1.1 offers given the caveats, but the rest of the feature list is excellent. With DivX support you can now take your old DivX shows and movies, re-encode them using Badaboom to save space. While trying to transcode a DivX file in the early version of Badaboom failed miserably, it worked just fine in the 1.1 preview.


oh wow, real settings

Main profile with CABAC support is also enabled, making Badaboom 1.1 closer to a real alternative for high quality rips of DVDs and Blu-rays. The 1.1 beta isn’t ready for prime time but I wanted to see what it could do, so I grabbed my Casino Royale Blu-ray, ripped it to the hard drive (resulting in a 46GB iso). The Blu-ray file structure is pretty straightforward, in the \BDMV\STREAM directory you’ll find a bunch of m2ts files, in this case the 34GB 00000.m2ts file is the main 1080p movie.


Please don't throw me in jail

Since I just ran the BD through AnyDVD HD it no longer had any encryption thus Badaboom was ok with transcoding it. To my surprise, it just worked. Using the Custom Media Center profile I was able to select a video bitrate of up to 25Mbps, I stuck with 11Mbps which should be enough for most < 50” HDTVs and normal viewing distances. The maximum audio bitrate is 320kbps, which is what I selected for the transcode. The resulting file was an 11.4GB .mp4 file that took 2 hours and 2 minutes to transcode at an average of 28.3 fps (note that this included the credits as well) on a GeForce GTX 280.


Click to Enlarge

The Blu-ray original was mastered at 24 fps, so with Badaboom on a GTX 280 we can get greater than real-time transcoding.

Delivering as promised, Elemental also enabled 1080p output with Badaboom 1.1. While I suspect that most people using to backup their Blu-ray collection will choose to go down to 720p since you can basically cut file sizes in half and maintain good enough quality for most HD displays.

The biggest limitation I see is that the output file is relatively useless on a HTPC. While Badaboom can provide a quick and easy way to rip a Blu-ray to a smaller, more backup-friendly format, you do lose the ability to preserve the DD/DTS audio tracks. Forget about lossless 7.1 support, I’m just talking about maintaining basic DD/DTS 5.1 that your HTPC/receiver are already setup to play.

Elemental still dodges the bullet of having to be a real Blu-ray backup solution by not addressing the audio side of the equation, but it’s clear where Badaboom is headed. I’m still looking into how well it fares on the image quality side compared to x264, but for now it looks like Badaboom 1.1 has potential in this department.

The real competition will be Intel’s Core i7 which, thanks to its incredible encoding performance can actually do quite well in the HD transcode department. NVIDIA has the advantage of its GPUs being much cheaper (you don’t have to buy a whole new platform) but at least at this point Intel has the quality advantage given that the best audio/video transcoding tools on the market are still x86-only and without a CUDA counterpart.

Image Quality Final Words
Comments Locked

36 Comments

View All Comments

  • Mark_12 - Sunday, May 23, 2021 - link

    W rzeczywistości, nie musisz czytać raportów, nawet jeśli znasz kasyno. jeśli jest licencjonowane oprogramowanie, zazwyczaj nie musisz się martwić o niezawodność. ja sam uwielbiam grać wieczorem, zazwyczaj właśnie tutaj https://vulkanvegas301.com/pl śledzę Twisting Slots i nie tylko. mają wiele odmian gier, które nie mogą nie zadowolić.
  • Mark_12 - Thursday, June 10, 2021 - link

    Hello everybody, how do you normally spend your free time? I am interested in gambling from you? I am a gambler and I have always liked to play at the casino. That is why I have decided to share my experience with you. Now I earn good time https://vulkanvegas.com/ca/category/slots . This is a proven onlone slots that is popular with players. I am sure you should definitely try playing here. On the site I threw away are all the necessary information you need, I am sure you will succeed.
  • SkullOne - Tuesday, December 16, 2008 - link

    GPU encoding is not supported by Vista 64-bit at this time. So if Vista 64-bit is being used that would explain why it was CPU based.

    This is straight from the 8.12 release notes: "The ATI Avivo video transcoder does not currently use GPU acceleration under Windows Vista 64-bit edition."

    Now with that said under Vista x64 I do not get nearly the same amount of corruption as seen on the review but I do get it. Hopefully those bugs are worked out in the future.

    I can successfully encode any VCD/SVCD MPEG to iPod size without a single issue. DivX files encode down to iPod size with some video corruption although it appears that the better the DivX encode the less corruption I get the in the iPod file. Xvid files just dump out audio with no video. I can't even try to covert an h.264/x264 based MKV file as Avivo doesn't recognize the container.

    Hopefully ATI addresses these issues quickly.
  • DigitalFreak - Tuesday, December 16, 2008 - link

    Wow, good catch. There was some mention of using Vista 32bit on a few encodes, but I have to wonder if they were using Vista 64bit during the timed run.
  • DerekWilson - Tuesday, December 16, 2008 - link

    We used 32-bit for everything but those 64-bit stills. AMD didn't tell us about the issues with 64-bit until we brought them up with them, so we switched half way through.

    All the performance tests were done on 32-bit vista.
  • DigitalFreak - Tuesday, December 16, 2008 - link

    Thanks for the clarification, Derek.
  • nissen - Tuesday, December 16, 2008 - link

    Is it Badaboom 1.0 you are using when talking about cpu usage? because here on my duo e6600/gtx280 badaboom eats just between 10-20% of the cpu depending on input ( ~15 for 1080i h264, ~20 for dvd ) , definatly something wrong.
  • MojaMonkey - Tuesday, December 16, 2008 - link

    On page 7 you have the 9800 GTX+ outperforming the GTX 260 is this correct or have you got the labels wrong?

    I'd expect the GTX 260 to perform better than a GTX+
  • dvinnen - Tuesday, December 16, 2008 - link

    "And since when is video transcoding not a deterministic process?"

    Cool product from AMD and I'm sure it will get better over the coming months, but how do you manage to do that? Weird.
  • The Preacher - Saturday, December 20, 2008 - link

    Ever heard of dithering? If you use that and seed the random generator using system time (not really a bright idea) you could get slightly different results each time (I doubt you could actually SEE the difference).
    http://en.wikipedia.org/wiki/Dithering">http://en.wikipedia.org/wiki/Dithering

Log in

Don't have an account? Sign up now