IPB

Welcome Guest ( Log In | Register )

23 Pages V  « < 16 17 18 19 20 > »   
Closed TopicStart new topic
IETF Opus codec now ready for testing, That's CELT 0.11
IgorC
post Oct 3 2012, 15:12
Post #426





Group: Members
Posts: 1581
Joined: 3-January 05
From: ARG/RUS
Member No.: 18803



You should get plenty of battery life as your EVO has 28 nm CPU. Mine is 45 nm and battery last 15 hours and 33 minutes on rockbox. http://rasher.dk/rockbox/android/
http://www.hydrogenaudio.org/forums/index....st&p=809617

Even more at 64 kbps.

This post has been edited by IgorC: Oct 3 2012, 15:14
Go to the top of the page
+Quote Post
The Sheep of DEA...
post Oct 4 2012, 07:48
Post #427





Group: Developer
Posts: 175
Joined: 16-April 06
Member No.: 29596



QUOTE (IgorC @ Oct 3 2012, 09:12) *
You should get plenty of battery life as your EVO has 28 nm CPU. Mine is 45 nm and battery last 15 hours and 33 minutes on rockbox. http://rasher.dk/rockbox/android/
http://www.hydrogenaudio.org/forums/index....st&p=809617

Even more at 64 kbps.


Thanks for the link to RockBox. Never tried it on here before, but I trust the maturity of the codebase (if not the interface) on mobile devices and ARM architecture more than VLC. It indeed plays the files with incredible ease, but the interface is non-existent (downloaded the 720x1280 but still, no controls visible and I had to guess where to tap -- eventually ended up playing, which is great). Comparison might not be as "fair" with VLC because RockBox doesn't work with Beats or Direct Volume Control like VLC seemed to. Also, VLC supports native ICS lockscreen and such, so right now it is probably the better player on the interface/app level.

I wonder what resampler (48KHz > 44.1KHz) VLC uses (linear for RockBox I believe). Either way, very promising news indeed!


--------------------
Copy Restriction, Annulment, & Protection = C.R.A.P. -Supacon
Go to the top of the page
+Quote Post
Serge Smirnoff
post Oct 11 2012, 21:53
Post #428





Group: Members
Posts: 371
Joined: 14-December 01
Member No.: 641



I wonder what is the correct (recommended) way to decode .opus files with 24 or 32 bit-depth accuracy. OpusDec outputs 16bit only with or without dithering. Foobar can convert .opus files to 24bit wavs but it is still unclear whether they are true 24bit outputs of the decoder or derived from 16bit outputs in some way.


--------------------
keeping audio clear together - soundexpert.org
Go to the top of the page
+Quote Post
saratoga
post Oct 12 2012, 02:12
Post #429





Group: Members
Posts: 5163
Joined: 2-September 02
Member No.: 3264



QUOTE (Serge Smirnoff @ Oct 11 2012, 16:53) *
I wonder what is the correct (recommended) way to decode .opus files with 24 or 32 bit-depth accuracy. OpusDec outputs 16bit only with or without dithering. Foobar can convert .opus files to 24bit wavs but it is still unclear whether they are true 24bit outputs of the decoder or derived from 16bit outputs in some way.


You could probably just modify it to dump the raw floats then convert them to whatever precision you wanted.
Go to the top of the page
+Quote Post
Dynamic
post Oct 12 2012, 11:01
Post #430





Group: Members
Posts: 833
Joined: 17-September 06
Member No.: 35307



QUOTE (Serge Smirnoff @ Oct 11 2012, 21:53) *
I wonder what is the correct (recommended) way to decode .opus files with 24 or 32 bit-depth accuracy. OpusDec outputs 16bit only with or without dithering. Foobar can convert .opus files to 24bit wavs but it is still unclear whether they are true 24bit outputs of the decoder or derived from 16bit outputs in some way.


Opusdec definitely tries to return the original bit depth and sampling rate and duration so as not to surprise the user. Internally, it works with floating point (unless compiled for fixed point). Doesn't it return 24-bit if the encoder's input was 24-bit. I could see it using only 16-bit as 24-bit is pointless for a lossy encoder, and really for anything in a final consumer delivery format, as Monty's blog post at xiph.org explains in detail.

fb2k is geared to playback and uses floating point processing architecture, so doesn't as yet pass these original parameters to the Converter to allow automatic resampling and dithering to the original bit depth and sampling rate when decoding Opus.

I'd be astounded if fb2k decoded Opus then converted to 16-bit anywhere before the end of the entire processing chain. That's just not the fb2k design philosophy! Simple to check though if you turn off dither in the Converter dialogue and choose your bit depth or output floats. You could even edit the OpusGain field in the Opus stream with a hex editor to turn it down by 100 dB, decode to 24-bit/32-bit Float in fb2k then apply 100 dB of gain to confirm it's not throwing it away.

This post has been edited by Dynamic: Oct 12 2012, 11:04
Go to the top of the page
+Quote Post
Serge Smirnoff
post Oct 12 2012, 11:47
Post #431





Group: Members
Posts: 371
Joined: 14-December 01
Member No.: 641



QUOTE (Dynamic @ Oct 12 2012, 14:01) *
Opusdec definitely tries to return the original bit depth and sampling rate and duration so as not to surprise the user. Internally, it works with floating point (unless compiled for fixed point). Doesn't it return 24-bit if the encoder's input was 24-bit. I could see it using only 16-bit as 24-bit is pointless for a lossy encoder, and really for anything in a final consumer delivery format, as Monty's blog post at xiph.org explains in detail.

For 48/24 input OpusDec returns 48/16. I foresee that 24bit input and output will be the most popular usage scenario for Opus because in most cases there is a need to resample input and output for the codec.

QUOTE (Dynamic @ Oct 12 2012, 14:01) *
I'd be astounded if fb2k decoded Opus then converted to 16-bit anywhere before the end of the entire processing chain. That's just not the fb2k design philosophy! Simple to check though if you turn off dither in the Converter dialogue and choose your bit depth or output floats. You could even edit the OpusGain field in the Opus stream with a hex editor to turn it down by 100 dB, decode to 24-bit/32-bit Float in fb2k then apply 100 dB of gain to confirm it's not throwing it away.

After your's and Peter's replies I'm pretty sure that Foobar can decode .opus with true 24bit accuracy. Your test suggestion is clever, not tried it yet though.


--------------------
keeping audio clear together - soundexpert.org
Go to the top of the page
+Quote Post
Gainless
post Oct 12 2012, 16:17
Post #432





Group: Members
Posts: 173
Joined: 28-October 11
Member No.: 94764



This one here might be a useful test sample for NullC as it's highly tonal and easy to ABX at high bitrates:

Albibeno Sample

The included ABX log is from a test with a 192 kbps file, encoded with the recent Opus tools.
Go to the top of the page
+Quote Post
Dynamic
post Oct 12 2012, 17:09
Post #433





Group: Members
Posts: 833
Joined: 17-September 06
Member No.: 35307



QUOTE (Serge Smirnoff @ Oct 12 2012, 11:47) *
For 48/24 input OpusDec returns 48/16. I foresee that 24bit input and output will be the most popular usage scenario for Opus because in most cases there is a need to resample input and output for the codec.


Hmm, for playback, I'd imagine you'd just decode to whatver your hardware supports, so that could well be 24-bit/48 kHz on most devices with no resampling (unless you have native 44.1kHz DSP like Rockbox). Many operating systems like Windows have native 48 kHz mixers unless you bypass to special modes so it's utterly pointless to go 48 -> 44.1 -> 48.

I'd imagine decoding to a PCM file is fairly rare use case compared to playback to the soundcard, and opusdec would in any case decode AND resample in floating point before switching to fixed-point PCM. The imperfections allowed by lossy encoding are usually far above 16-bit quantization noise.
You might then indirectly resample that PCM (with calculations carried out at 24 or 32-bit) if, for some reason, you chose to play it over your soundcard via e.g. Windows Mixer at 48kHz.

Any added noise is broad-spectrum, and only adds up to -90 to -95 dB over the entire bandwidth. The ear is more of a spectrum analyzer than an oscilloscope. Over the ear's typical discriminating bandwidth it is probably about 110-120 dB below a full-scale sinusoid at the same frequency and even with music mastered with 20 dB of headroom, that's over 90 dB per band. Considering a very quiet room is about 30 dB SPL, pretty loud music is 90 dB SPL and pain is about 120 dB SPL, that's plenty unless you start turning up the volume hugely during fade-outs.

Sure it's always good practice to process and edit at 24 bits or better to prevent significant accumulation of noise over many many multiple editing processes and echo and reverb, but for regular listening even with pretty heavy dynamic range compression, it should be overkill by quite a big margin.
Go to the top of the page
+Quote Post
NullC
post Oct 13 2012, 03:23
Post #434





Group: Developer
Posts: 200
Joined: 8-July 03
Member No.: 7653



QUOTE (Dynamic @ Oct 12 2012, 08:09) *
Hmm, for playback, I'd imagine you'd just decode to whatver your hardware supports, so that could well be 24-bit/48 kHz on most devices with no resampling (unless you have native 44.1kHz DSP like Rockbox). Many operating systems like Windows have native 48 kHz mixers unless you bypass to special modes so it's utterly pointless to go 48 -> 44.1 -> 48.

I'd imagine decoding to a PCM file is fairly rare use case compared to playback to the soundcard, and opusdec would in any case decode AND resample in floating point before switching to fixed-point PCM. The imperfections allowed by lossy encoding are usually far above 16-bit quantization noise.
You might then indirectly resample that PCM (with calculations carried out at 24 or 32-bit) if, for some reason, you chose to play it over your soundcard via e.g. Windows Mixer at 48kHz.
Right, our recommendation is to only preserve the original rate for file output; for playback you playback at 48kHz preferably, whatever you can do otherwise (with resampling).

Opusdec does this. And for the float->16 bit conversion it uses a proper noise shaping triangular dither with a conservative shaping filter that limits the HF noise boost. Why bother? Why not. You can construct crazy cases where the intermod from straight truncated quantization is audible... and I don't know how loud the signal will be played back. It probably doesn't matter, but on desktops CPU time is free relative to how much work it takes. tongue.gif (plus you can turn it off)

I'll gladly take a patch to add float output, I just couldn't be bothered to figure out the required wav magic, though the reader code for opusenc handles it. tongue.gif
Go to the top of the page
+Quote Post
jmvalin
post Oct 13 2012, 04:18
Post #435


Xiph.org Speex developer


Group: Developer
Posts: 487
Joined: 21-August 02
Member No.: 3134



QUOTE (Gainless @ Oct 12 2012, 11:17) *
This one here might be a useful test sample for NullC as it's highly tonal and easy to ABX at high bitrates:

The included ABX log is from a test with a 192 kbps file, encoded with the recent Opus tools.


I just checked and the latest code in master (just merged from exp_analysis branch) actually detects this as highly tonal and increase the bit-rate way up. This should be enough to fix the problem (please try it and let me know).
Go to the top of the page
+Quote Post
Serge Smirnoff
post Oct 13 2012, 09:39
Post #436





Group: Members
Posts: 371
Joined: 14-December 01
Member No.: 641



QUOTE (Dynamic @ Oct 12 2012, 19:09) *
QUOTE (Serge Smirnoff @ Oct 12 2012, 11:47) *
For 48/24 input OpusDec returns 48/16. I foresee that 24bit input and output will be the most popular usage scenario for Opus because in most cases there is a need to resample input and output for the codec.


Hmm, for playback, I'd imagine you'd just decode to whatver your hardware supports, so that could well be 24-bit/48 kHz on most devices with no resampling (unless you have native 44.1kHz DSP like Rockbox). Many operating systems like Windows have native 48 kHz mixers unless you bypass to special modes so it's utterly pointless to go 48 -> 44.1 -> 48. ....................
Sure it's always good practice to process and edit at 24 bits or better to prevent significant accumulation of noise over many many multiple editing processes and echo and reverb, but for regular listening even with pretty heavy dynamic range compression, it should be overkill by quite a big margin.


24bit output is important not only because of resampling of course; consuming of audio becomes more and more sophisticated on listener's side today - at least using of some DSP is presupposed, not to say about mixing with other audio and frequent necessity to transcode to lower bitrates. From this perspective the use of 16bit audio and corresponding bit reduction techniques look supplementary while 24bit audio chain on consumer side looks quite natural and even more simple.


--------------------
keeping audio clear together - soundexpert.org
Go to the top of the page
+Quote Post
Gainless
post Oct 14 2012, 11:48
Post #437





Group: Members
Posts: 173
Joined: 28-October 11
Member No.: 94764



QUOTE (jmvalin @ Oct 13 2012, 05:18) *
QUOTE (Gainless @ Oct 12 2012, 11:17) *
This one here might be a useful test sample for NullC as it's highly tonal and easy to ABX at high bitrates:

The included ABX log is from a test with a 192 kbps file, encoded with the recent Opus tools.


I just checked and the latest code in master (just merged from exp_analysis branch) actually detects this as highly tonal and increase the bit-rate way up. This should be enough to fix the problem (please try it and let me know).


Sorry, I don't really get what you mean (English is not my native language). Is there already a newer "official" encoder version than the one from the 0.1.5 Opus tools or do you just talk about the last exp_analysis branch?
Go to the top of the page
+Quote Post
nu774
post Oct 14 2012, 12:03
Post #438





Group: Developer
Posts: 565
Joined: 22-November 10
From: Japan
Member No.: 85902



QUOTE (Gainless @ Oct 14 2012, 19:48) *
Sorry, I don't really get what you mean (English is not my native language). Is there already a newer "official" encoder version than the one from the 0.1.5 Opus tools or do you just talk about the last exp_analysis branch?

My English is even worse, but he's saying that PSY tuning developed under exp_analysis7 branch was merged into main branch recently, therefore soon it will become "official".
(This merge was committed at Oct 9, so current official win32 binary (0.15) doesn't include this).
CODE
commit 7315b35e13a3a7c504ed6b1fe2d28ad500eb2701
Merge: ca82894 317ffc2
Author: Jean-Marc Valin <jmvalin@jmvalin.ca>
Date:   Tue Oct 9 03:07:06 2012 -0400

    Merge branch 'exp_analysis7'

    Conflicts:
        celt/celt.c
        celt/mdct.c
        include/opus_defines.h
        src/opus_encoder.c
Go to the top of the page
+Quote Post
Gainless
post Oct 14 2012, 12:19
Post #439





Group: Members
Posts: 173
Joined: 28-October 11
Member No.: 94764



QUOTE (nu774 @ Oct 14 2012, 13:03) *
QUOTE (Gainless @ Oct 14 2012, 19:48) *
Sorry, I don't really get what you mean (English is not my native language). Is there already a newer "official" encoder version than the one from the 0.1.5 Opus tools or do you just talk about the last exp_analysis branch?

My English is even worse, but he's saying that PSY tuning developed under exp_analysis7 branch was merged into main branch recently, therefore soon it will become "official".
(This merge was committed at Oct 9, so current official win32 binary (0.15) doesn't include this).
CODE
commit 7315b35e13a3a7c504ed6b1fe2d28ad500eb2701
Merge: ca82894 317ffc2
Author: Jean-Marc Valin <jmvalin@jmvalin.ca>
Date:   Tue Oct 9 03:07:06 2012 -0400

    Merge branch 'exp_analysis7'

    Conflicts:
        celt/celt.c
        celt/mdct.c
        include/opus_defines.h
        src/opus_encoder.c



Thanks for the explanation, I guessed it somehow but wasn't sure. Would be nice to have a compiled exe of this btw. Can someone upload it?

This post has been edited by Gainless: Oct 14 2012, 12:21
Go to the top of the page
+Quote Post
brat-h
post Oct 22 2012, 01:54
Post #440





Group: Members
Posts: 3
Joined: 24-January 12
Member No.: 96664



QUOTE
Would be nice to have a compiled exe of this btw. Can someone upload it?


Here is the Cygwin-build for win32 of the latest source code of opus-tools with the latest opus-codec as for now.

http://rghost.ru/41081608

This post has been edited by brat-h: Oct 22 2012, 02:28
Go to the top of the page
+Quote Post
Gainless
post Oct 22 2012, 15:14
Post #441





Group: Members
Posts: 173
Joined: 28-October 11
Member No.: 94764



QUOTE (brat-h @ Oct 22 2012, 02:54) *
QUOTE
Would be nice to have a compiled exe of this btw. Can someone upload it?


Here is the Cygwin-build for win32 of the latest source code of opus-tools with the latest opus-codec as for now.

http://rghost.ru/41081608

Thank you very much!
I've tested the sample once again with the new version and could still ABX it at 192 kbps.

CODE
foo_abx 1.3.4 report
foobar2000 v1.1.14
2012/10/22 15:19:40

File A: C:\Dokumente und Einstellungen\Master O\Desktop\Albibeno (Sample).flac
File B: C:\Dokumente und Einstellungen\Master O\Desktop\Albibeno (Sample).opus

15:19:40 : Test started.
15:19:55 : 01/01 50.0%
15:20:49 : 02/02 25.0%
15:21:13 : 03/03 12.5%
15:21:34 : 04/04 6.3%
15:39:18 : 05/05 3.1%
15:39:38 : 06/06 1.6%
15:39:51 : 06/07 6.3%
15:41:11 : 07/08 3.5%
15:41:32 : 08/09 2.0%
15:42:38 : 08/10 5.5%
15:42:54 : 09/11 3.3%
15:43:21 : 10/12 1.9%
15:43:49 : 11/13 1.1%
15:45:11 : 12/14 0.6%
15:45:23 : Test finished.

----------
Total: 12/14 (0.6%)


I'm not sure if the result is of any worth though, as I used the Direct Sound output of Windows XP, which is known for its terrible resampler. The artifact I noticed is a slight distortion on the echo of the first two notes (right channel), which makes this sound a bit sharper. Maybe someone can verifiy it?

This post has been edited by Gainless: Oct 22 2012, 15:16
Go to the top of the page
+Quote Post
IgorC
post Oct 22 2012, 15:58
Post #442





Group: Members
Posts: 1581
Joined: 3-January 05
From: ARG/RUS
Member No.: 18803



You can try to set a native (the same as .opus file) sample rate to avoid possible resampling-related issues and/or resample the output with SoX with very high quality VHQ (which is transparent rolleyes.gif ).

I would try to resample (44.1 kHz -> 48kHz) the original before encode to Opus with SoX VHQ resampler, just to see if it's not built-in Opus'es resampler.

This post has been edited by IgorC: Oct 22 2012, 15:59
Go to the top of the page
+Quote Post
foxyshadis
post Oct 23 2012, 09:44
Post #443





Group: Members
Posts: 42
Joined: 28-March 06
Member No.: 28917



QUOTE (brat-h @ Oct 21 2012, 17:54) *
QUOTE
Would be nice to have a compiled exe of this btw. Can someone upload it?


Here is the Cygwin-build for win32 of the latest source code of opus-tools with the latest opus-codec as for now.

http://rghost.ru/41081608

After almost pulling my hair out wondering why encodes with the exp7-merged branch were coming out bit-identical, I finally realized that the only changes were for CELT frames. Mine, at 96 kbps, are never getting anywhere near that low, so they're never hitting the analysis at all. At 192, I would expect the decodes to be bit-identical; you might want to test that before spending too much time abxing. The other changes since have just been minor bugfixes.

This post has been edited by foxyshadis: Oct 23 2012, 09:44
Go to the top of the page
+Quote Post
LithosZA
post Oct 23 2012, 10:53
Post #444





Group: Members
Posts: 203
Joined: 26-February 11
Member No.: 88525



QUOTE
Here is the Cygwin-build for win32 of the latest source code of opus-tools with the latest opus-codec as for now.

http://rghost.ru/41081608

Thanks for posting that. I saw there was a 'cygopus-0.dll' in the archive.

I quickly created a C# project to see if I can call any methods:

CODE
[DllImport("cygopus-0.dll", CallingConvention = CallingConvention.Cdecl, CharSet = CharSet.Ansi)]
public static extern string opus_get_version_string();


Once I called 'opus_get_version_string()' I received 'libopus 1.0.1'. Yay!

I think it would be nice if the next 'opus tools' release includes win32 dlls like this one. (Or a seperate download for the libopus dll)
Go to the top of the page
+Quote Post
Gainless
post Oct 23 2012, 13:05
Post #445





Group: Members
Posts: 173
Joined: 28-October 11
Member No.: 94764



QUOTE (foxyshadis @ Oct 23 2012, 10:44) *
QUOTE (brat-h @ Oct 21 2012, 17:54) *
QUOTE
Would be nice to have a compiled exe of this btw. Can someone upload it?


Here is the Cygwin-build for win32 of the latest source code of opus-tools with the latest opus-codec as for now.

http://rghost.ru/41081608

After almost pulling my hair out wondering why encodes with the exp7-merged branch were coming out bit-identical, I finally realized that the only changes were for CELT frames. Mine, at 96 kbps, are never getting anywhere near that low, so they're never hitting the analysis at all. At 192, I would expect the decodes to be bit-identical; you might want to test that before spending too much time abxing. The other changes since have just been minor bugfixes.

Sorry, but you lost me with the "CELT frames" and "hitting the analysis" part, can you explain that a bit further? I've compared the new master with the recent exp versions yet btw, and they differ at the bitrates and RG peaks, so I guess there happened more than just minor bugfixing at the updates.

This post has been edited by Gainless: Oct 23 2012, 13:39
Go to the top of the page
+Quote Post
jmvalin
post Oct 23 2012, 13:58
Post #446


Xiph.org Speex developer


Group: Developer
Posts: 487
Joined: 21-August 02
Member No.: 3134



QUOTE (foxyshadis @ Oct 23 2012, 04:44) *
After almost pulling my hair out wondering why encodes with the exp7-merged branch were coming out bit-identical, I finally realized that the only changes were for CELT frames. Mine, at 96 kbps, are never getting anywhere near that low, so they're never hitting the analysis at all. At 192, I would expect the decodes to be bit-identical; you might want to test that before spending too much time abxing. The other changes since have just been minor bugfixes.


Actually, the changes in exp_analysis7 (which are now in master) do affect 96 kb/s. If you're seeing bit-identical output, you're doing something wrong.
Go to the top of the page
+Quote Post
foxyshadis
post Oct 23 2012, 19:02
Post #447





Group: Members
Posts: 42
Joined: 28-March 06
Member No.: 28917



QUOTE (jmvalin @ Oct 23 2012, 05:58) *
QUOTE (foxyshadis @ Oct 23 2012, 04:44) *
After almost pulling my hair out wondering why encodes with the exp7-merged branch were coming out bit-identical, I finally realized that the only changes were for CELT frames. Mine, at 96 kbps, are never getting anywhere near that low, so they're never hitting the analysis at all. At 192, I would expect the decodes to be bit-identical; you might want to test that before spending too much time abxing. The other changes since have just been minor bugfixes.


Actually, the changes in exp_analysis7 (which are now in master) do affect 96 kb/s. If you're seeing bit-identical output, you're doing something wrong.

Not sure which, but I swear I ran the exact same conversions this morning as yesterday, and today the exp branch is hugely different on the same songs. (120kbps vs 97kbps on one track, 65 vs 94 on another.) Yesterday, only the library name and frame headers were different at all. I built it myself a few times and didn't change anything but the bitrates in FB's converter, even checked the process command lines in process explorer; but whatever, it is obviously doing something now.
Go to the top of the page
+Quote Post
The Sheep of DEA...
post Nov 1 2012, 06:29
Post #448





Group: Developer
Posts: 175
Joined: 16-April 06
Member No.: 29596



Poweramp gained OPUS support! Posted two days ago, "Opus is successfully added to current Poweramp dev builds, including opus in .opus and .ogg files, full gapless and replay gain support."

To commemorate the occasion, here is a CVS-master compile of opus-tools (use opusenc to encode), including dlls for libopus and libogg (1.3.0).

This is today's Opus as well as today's opus-tools, featuring the new experimental tweaks (the now-merged exp_analysis7 branch). It's also 3 times as fast as brat-h's cygwin compile above on my system (requires SSE).

This post has been edited by The Sheep of DEATH: Nov 1 2012, 06:34
Attached File(s)
Attached File  opus_tools_11_1_2012.zip ( 591.25K ) Number of downloads: 143
 


--------------------
Copy Restriction, Annulment, & Protection = C.R.A.P. -Supacon
Go to the top of the page
+Quote Post
Seren
post Nov 1 2012, 17:33
Post #449





Group: Members
Posts: 59
Joined: 1-November 12
Member No.: 104244



QUOTE (The Sheep of DEATH @ Nov 1 2012, 13:29) *
Poweramp gained OPUS support! Posted two days ago, "Opus is successfully added to current Poweramp dev builds, including opus in .opus and .ogg files, full gapless and replay gain support."

To commemorate the occasion, here is a CVS-master compile of opus-tools (use opusenc to encode), including dlls for libopus and libogg (1.3.0).

This is today's Opus as well as today's opus-tools, featuring the new experimental tweaks (the now-merged exp_analysis7 branch). It's also 3 times as fast as brat-h's cygwin compile above on my system (requires SSE).


Thx The Sheep of DEATH, it also encodes much faster than the official release (45x vs 30x for me).
Though I'm having a hard time deciding which is better quality... The bitrate varies quite a lot but I managed to compare a few at the same bitrate (can't disclose what I thought sounded better since my I don't have the time or patience to do a proper ABX).
Go to the top of the page
+Quote Post
The Sheep of DEA...
post Nov 3 2012, 19:42
Post #450





Group: Developer
Posts: 175
Joined: 16-April 06
Member No.: 29596



QUOTE (Seren @ Nov 1 2012, 11:33) *
Thx The Sheep of DEATH, it also encodes much faster than the official release (45x vs 30x for me).
Though I'm having a hard time deciding which is better quality... The bitrate varies quite a lot but I managed to compare a few at the same bitrate (can't disclose what I thought sounded better since my I don't have the time or patience to do a proper ABX).


Glad to hear it! Besides much more drastic bitrate fluctuations, a definitive improvement in ringing is noticeable on one of my samples at (specified) 68kbps. The old version produced a file at 62kbps (with ringing on the vocals), while the new version produced a file that was over 74kbps (with ringing much reduced on the vocals). The instrumental version (w/o vocals) of the same song came out to be nearly identical in bitrate (62 old, 63 new).

Interesting.


--------------------
Copy Restriction, Annulment, & Protection = C.R.A.P. -Supacon
Go to the top of the page
+Quote Post

23 Pages V  « < 16 17 18 19 20 > » 
Closed TopicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 26th December 2014 - 00:36