Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Recent Posts
1
Lossless / Other Codecs / Re: Monkey's Audio 9.10 beta with additional SIMD optimizations
Last post by Skymmer -
Good day to everybody. First of all, thanks to developers for this beta! Its good to see that development of Monkey's Audio goes on. Also thanks to all of the people who participated in testing!
I decided to add my 5 cents so here it comes )
Please note that my test is kinda dirty and synthetic.
Test material: Generated 300 seconds of spatial stereo brown noise with Adobe Audition and saved it as 32bit float, with further conversion to 16/24/32 bit via LibSndFile.
Hardware: i7-3770K @ 4500 MHz, SSD (SATA3 speed limited)
Software: Windows 7 x64, measurements with ProcProfile 1.5.1
I'm posting results as screenshot from Excel.
Actually I haven't post here for a long time so dunno if it will look OK, so sorry if post will look a little bit clumsy )
In order somebody would like to have an original Excel file, I've attached it too.

X

So, results are kinda interesting and bring a couple of strange things.
1. Decoding is notably slower than encoding. Well, its a curse of almost all symmetric encoders I have seen so far and solution here is either PGO (profile guided optimization), either push out decoder to standalone executable, or simply don't care :)
2. -c1000 mode for 24bit resolution presumably broken or lacks the optimizations. Both -c2000 and -c3000 are actually faster than -c1000 for 24bit audio. Well, at least for this file.
Can anybody confirm it ?
3. Results for 32bit -c5000 look strange to me. For 9.10 beta we have:
For 16bit, -c5000 mode 2.25 times slower than -c4000
For 24bit, -c5000 mode 2.19 times slower than -c4000
For 32bit, -c5000 mode 2.57 times slower than -c4000
Of course I do not expect that there should be some kind of linear coefficients for speed but anyway, just pointing to this.

Anyway, with more than 25% (maximum) and almost 9% (average) speedup, the results are simply astonishing!
My congratulations !
2
MP3 - Tech / Re: History: where did the "1152" originate?
Last post by saratoga -
Quote from: Porcus on
Quote from: saratoga on
MP3 just uses a weird size

Yes, and the question of the topic is: why did they choose that weird size?

The link above explains in more detail. but you have 32 subbands each with 18 spectral points.  The 50% overlap then doubles that length to 1152.  You can't have 2*588 samples because that wouldn't divide evenly into 32 subbands.  The actual number of subbands and points per subband are to maintain compatibility with layer 2, itself based on MUSICAM.
3
3rd Party Plugins - (fb2k) / Re: Playlist-Tools-SMP
Last post by regor -
Some time ago I added a icons-only mode, which hopefully I have finally completed today.
  • Global switch.
  • Switch per button.
  • Option to expand on mouse hover (on final release, it will be smoother)
  • Reworked all tooltips, to unify their info and appearance (and output the buttons menu when using the icons-only mode).
  • Only works on X orientation (because on vertical buttons, there is no way to expand the panel...)
  • All button icons will be revised, to ensure they are more or less identifiable only by icon.
  • There were buttons with customizable names, and now also with customizable icons.

Spoiler (click to show/hide)
7
MP3 - Tech / Re: History: where did the "1152" originate?
Last post by saratoga -
1152 samples is twice the length of the hybrid filterbank for long blocks.  Since the filter bank uses 50% overlap, you get twice as many samples back.  This is actually really common in transform codecs, usually the frame size is twice the transform size due to how the MDCT works.  MP3 just uses a weird size rather than the more common 1024 point MDCT -> 2048 sample frame size you see in pure MDCT codecs. 

See here:  https://wiki.hydrogenaud.io/index.php?title=MP3#The_hybrid_polyphase_filterbank