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.
Topic: Nontransparent example at 231kbps (Read 2465 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Nontransparent example at 231kbps

I don't know if this forum accepts test signals as killer samples or not, but this issue does not happen with other Codecs so I'd just post my findings.

[1] Try tone.wav and toneClick.wav and calibrate your listening volume so that the click in toneClick.wav can be easily heard. This step is to ensure you are listening at an optimal level, not too loud or too quiet.

[2] Then ABX toneClick.wav vs the opus file, the artifacts should be super obvious.

According to my tests, other Codecs (Lame, Winamp AAC, Vorbis) can achieve transparency below 100kbps with toneClick.wav, only Opus exhibits these artifacts. The Opus encoder version is same the one on the Opus website, as well as the one included in the foobar encoder pack, encoded using the foobar GUI VBR slider, without any custom parameters.

Re: Nontransparent example at 231kbps

Reply #1
Killer samples are accepted. In this case it's rather a synthetic/generated sound — and these kind of samples are more a proof of concept than a real annoyance for users.

The Opus file you joined in your 7z archives is named "105kbps" and the output bitrate is 231 kbps as you mention it in the title. Correct me if I'm wrong, but you probably set Opus to 105 kbps. As Opus usually use much more bit with highly tonal sample, you get a very high bitrate on this short piece of sound. In other words you find an artifact with opus -105 and not with opus -231. That makes a big difference.
Indeed, while Opus at ~100 kbps is usually transparent some artifacts may be audible (especially on very special sounds like this one).


If I understand you description correctly you hear an artifact on the exact moment of the light "clic" of the ToneClick sample. Do you also ear the alteration of the tonal sound? Can you ABX Tone.wav vs Tone.opus?
Because I hear a very strong alteration of the whole sample (with or without clic):

Quote
foo_abx 2.0.6d report
foobar2000 v1.6.6 beta 4
2021-05-01 12:54:07

File A: tone.wav
SHA1: 561ecac961f6714ef9de05d8ff52db97e2351eb7
Gain adjustment: -1.40 dB
File B: tone.opus
SHA1: 3fd43651750a075f01e76f63317a2b57261334c6
Gain adjustment: -1.42 dB

Output:
Default : Primary Sound Driver
Crossfading: NO

12:54:07 : Test started.
12:54:12 : 01/01
12:54:22 : 02/02
12:54:26 : 03/03
12:54:30 : 04/04
12:54:33 : 05/05
12:54:37 : 06/06
12:54:41 : 07/07
12:54:46 : 08/08
12:54:46 : Test finished.

 ----------
Total: 8/8
p-value: 0.0039 (0.39%)

 -- signature --
c9491f26aad31218d75b5d8cd7f4fc140af999a2

In this test Tone.wav was encoded at 105 kbps (final bitrate: 231 kbps as well). So no clic but obvious difference to my ears.

Cheers!

Re: Nontransparent example at 231kbps

Reply #2
If I understand you description correctly you hear an artifact on the exact moment of the light "clic" of the ToneClick sample. Do you also ear the alteration of the tonal sound? Can you ABX Tone.wav vs Tone.opus?
The tonal distortion is the obvious difference, not the click. The click also serves the purpose as testing other Codecs' ability to encode small transients. For example, the tones in the attached "90" wma file are not distorted to my ears, but the click can no longer be heard.

The wma files were encoded using Adobe Audition 1.5's built-in encoder, with VBR settings. The highest possible setting is "98" and I used the "90" setting.

Re: Nontransparent example at 231kbps

Reply #3
OK, thanks for the clarification.
This short sample is at least an evidence that even strong bitrate variations are not always helpful to avoid distortions. Here the bitrate is more than twice higher than average but quality is much worse than what Opus produces at ~100 kbps.

If I'm not wrong Opus had in the past some known issues with tonal samples at low bitrate. From Wikipedia:
Quote
On December 5, 2013, libopus 1.1 was released, incorporating overall speed improvements and significant encoder quality improvements: Tonality estimation boosts bitrate and quality for previously problematic samples, like harpsichords.

On my side I noticed than Opus 1.3.x uses on average more bitrate for classical music and quality is also much less stellar at low bitrate than with rock for example. This sample seems to be a concentrate of this characteristic and of the lack of efficiency on a certain kind of sound signal.

Re: Nontransparent example at 231kbps

Reply #4
I used this page to help me convert the toneClick.wav to common Opus bitrates: https://wiki.hydrogenaud.io/index.php?title=Opus#Music_encoding_quality

I tried:
96kbps
105kbps (the number you used)
112kbps
128kbps
160kbps
192kbps
231kbps (this was a just in case I misunderstood measure, but was not necessary)

Every conversion at or above 112kbps I believe was free of the distortion. While the distortion itself is obvious when it occurs, I noticed in Foobar2000 the little visualizer at the top was showing the distortion on the rightmost bar in the form of it moving rapidly, which would instead be steady at or above 112kbps. What this has convinced me of at the very least, is that 128kbps Opus is probably a safe conversion number to avoid such obvious distortion. I would assume it is something about how Opus processes sound when converted at around 105kbps and below, that makes this sample not convert well. I'm not sure if this would be a fair indicator of the quality of the sound Opus produces relative to other formats at higher bitrates (perhaps starting at 112kbps and above).

I'm no expert by any means, just sharing my findings, layman guesses and limited understandings.

Re: Nontransparent example at 231kbps

Reply #5
I noticed in Foobar2000 the little visualizer at the top
If I talked something about this my post would be in the recycle bin now.

Whether 112kbps (as target, rather than actual encoded bitrate like 231kbps in this specific example) is transparent or not depends on materials and listeners, so I am not going to convince (or being convinced by) anyone that a specific bitrate is good enough for something, individuals can always use their preferred materials to do some listening tests.

This target bitrate vs actual bitrate issue could be important in cases where storage space is crucial, for example, when someone wants to fit a number of files in an optical disc. The ideal situation is that the files should optimally utilize the disc's space (e.g. 4.3GB for a DVD or 700MB for a CD) rather than far below or above the target. Not as common in audio codecs but video codecs often offer multi-passes mode to achieve a target bitrate. Fail to meet the target is a big annoyance because high quality video encoding is a time consuming process. If it is irrelevant to what you wanted to do and you don't want to do any listening tests yourself then it is really up to you to follow the wiki or not, I am not going to give any suggestions.

Re: Nontransparent example at 231kbps

Reply #6
"I noticed in Foobar2000 the little visualizer at the top"

When I said that quote it was as a side note of a consistent pattern I noticed when I was nearly finished my listening tests. My original judgment of 112kbps as not having the distortion that is present at 105kbps (the number you used to convert the file from .wav), was based on no longer hearing the obvious distortion. You can check for yourself whether in this specific case the distortion is still present when you convert the .wav at 112kbps, versus the 105kbps you used. To make it clearer it was specifically my ears that did not detect the distortion at 112kbps, but did at 105kbps.

But I noticed after that, a consistent pattern that the visualizer does in fact visually show in the way that I described, the distortion in question, only in the files where it is present. I was not however using that as my measure of when the distortion was present originally, and would never use it as the main basis for concluding such distortion is or is not present. It was just what I still think is an interesting observation, that it actually shows up visually only in the files in which the distortion is present.

And again if this has shown me anything, it is that it is fairly likely, but perhaps not impossible that 128kbps or above will not have extreme issues such as this, since this was likely an extreme example of something Opus handles poorly at around 105kbps or below.

As far as why I shared the wiki page, it was to show what I was using as reference for commonly used bitrates that I chose to compare against each other, and with the file converted to the custom value of 105kbps that you chose.

I'm leaning towards Opus 160kbps or 192kbps as the numbers I'd convert my personal music library to just to ensure optimal quality under all circumstances, but it is interesting to see what lower values are capable and incapable of, and this extreme example of Opus failing to deliver relatively transparent sound at around 105kbps, but seeming to be relatively fine at 112kbps, intrigued me enough to share my findings.

Basically, to be on the safe side, if this sample you provided is any indication, which it may not be, around 112kbps is probably the lowest people should use if they wish to prevent such distortion. I'm now curious if other samples would reveal this degree of extreme distortion with conversions at or higher than 112kbps. If so, I'd then raise what I'd consider at that point the relatively safe lower limit, if one wishes to avoid this kind of issue when converting audio files. I would like to know at what bitrate (such as 128kbps just as an example) these kinds of extreme examples of distortion can no longer be detected in any sample when using the Opus format.

Btw, I made no attempt to "convince" you of anything, these are just my observations. I think you misunderstood why I brought up the visualizer thing, and you may have assumed I didn't do any actual listening tests, which is wrong.

Again: "I'm no expert by any means, just sharing my findings, layman guesses and limited understandings."

Re: Nontransparent example at 231kbps

Reply #7
As I generated the files myself, I am fully aware of how the files look like in lossless and lossy forms in various codecs.

Why 105kbps? Because for this specific file, 106kbps is transparent to me, and the smallest adjustment interval in the GUI is 1kbps. Other codecs like mp3 for example uses the -V parameter for VBR adjustment, not kbps. The purpose of my initial post was to indicate that the test file has a significantly higher transparency bitrate threshold than other codecs, not about which target bitrate is appropriate, too high/low or something similar. Also, not about which codec is better or poorer in general. Obviously a single file cannot be used to test everything.

Basically, what you care about is not really related to this thread, for what you interested, perhaps you can talk about them in other threads, with test files and log files.

Re: Nontransparent example at 231kbps

Reply #8
As far as I'm aware everything I said is related to the topic in various ways, but it may not be precisely the aspects you want to talk about, and it seems you don't want any deviation from precisely what you want to talk about. Once this comment is posted, if I leave any further responses, I will refrain from speaking about anything I think deviates from the specifics of the topic you seem to want to talk about, as long as something you may say in response to this or potential future comments of mine in this topic, don't make reference to what I said earlier. I'm sorry if you were not interested in what I had to share, hopefully some others who might see my messages will be.

I still think just as much that some of what I shared in combination with some of the rest of what was said in this topic, was at least potentially useful information that could in the end among other things be used to improve how Opus converts at such low bitrates if the developers knew (assuming they don't, and were to find out thanks to the contents of topics like this) and were willing and able (assuming it's possible within Opus without making compromises that cause other problems) to fix such samples ending up as distorted as this is at apparently according to your tests (I've not tried 106kbps but I have little doubt it's true), exactly 105kbps or below. I did an ABX comparison of the files at 105kbps and 112kbps just to check a little earlier, and I was able to get 25 out of 25 correct. I can share the results file if you wish, but since you already said you find the file transparent at 106kbps, I assume that is not something you would care to see.

I still think it's interesting that the tiny visualizer in Foobar2000 was able to present that variation in the size of the last bar only (all other bars were visually consistent whether the file was distorted or not) in the distorted files, and never in the files that contained no distortion, where that last bar remained the same size. I thought it was interesting just as a small observation that was a true visual indicator in this specific case, dependent on which files objectively contained audible distortion or not. This is true even when comparing the 105kbps file to the 112kbps Opus file, and if what you said is true, is probably the case when comparing the 105kbps file to a 106kbps Opus file.

In response to what seemed to be one of the prime focuses of your first comment's opposition to what I shared in my first comment, when I said, "What this has convinced me of at the very least, is that 128kbps Opus is probably a safe conversion number to avoid such obvious distortion." The key parts are "convinced me", as opposed to me attempting to convince anyone else (something it seems you may have thought I was doing based on what you said), and "probably", as in there is uncertainty. Me being convinced that something is likely, does not mean I'm incapable of changing my mind if evidence to the contrary were to be presented. Basically, while 112kbps (and as low as 106kbps according to your findings; I haven't tried lower than 112kbps) was enough in this case to remedy the issue, 128kbps may (but might not in perhaps very rare cases) provide enough of a safety net to prevent similar extreme distortion issues in most or all cases, but further testing would be needed with many other samples to even come close to saying this is the case in something like a 99.99%+ range of samples that could be examined.

Btw, I think your title would have been a little clearer if you'd said 105kbps instead, because I don't think people usually refer to the end result bitrate that the file ends up at after conversion, they refer to the chosen Opus bitrate it was converted at. Is that wrong? What does that 231kbps in this case indicate anyways, and for all other audio files? Is it the highest bitrate at any point/s in the audio file/s, and all other parts of them may vary somewhere at or below, in this case 231kbps? Or is it something else, perhaps an average bitrate? I'd assume not the latter (an average) since that seems to me like it may be a less useful number, though there's a good chance I don't understand why it would be useful, if that does indicate the average. I would have been very surprised if you'd converted the file at 231kbps and it has this sort of distortion. The first person to respond to you in this topic also seemed to indicate your title was a bit misleading, though I imagine it is unintentionally so.

As a final note, I tend to type a lot when I am interested enough in something and/or inspired to, so I apologize if this post did not contain sufficient brevity for individuals' personal tastes.

[Edits made included fixing some minor typos, and word changes for clarity as to my intended meanings.]

 

Re: Nontransparent example at 231kbps

Reply #9
I still think just as much that some of what I shared in combination with some of the rest of what was said in this topic, was at least potentially useful information that could in the end among other things be used to improve how Opus converts at such low bitrates if the developers knew (assuming they don't, and were to find out thanks to the contents of topics like this) and were willing and able (assuming it's possible within Opus without making compromises that cause other problems) to fix such samples ending up as distorted as this is at apparently according to your tests (I've not tried 106kbps but I have little doubt it's true), exactly 105kbps or below. I did an ABX comparison of the files at 105kbps and 112kbps just to check a little earlier, and I was able to get 25 out of 25 correct. I can share the results file if you wish, but since you already said you find the file transparent at 106kbps, I assume that is not something you would care to see.

I still think it's interesting that the tiny visualizer in Foobar2000 was able to present that variation in the size of the last bar only (all other bars were visually consistent whether the file was distorted or not) in the distorted files, and never in the files that contained no distortion, where that last bar remained the same size. I thought it was interesting just as a small observation that was a true visual indicator in this specific case, dependent on which files objectively contained audible distortion or not. This is true even when comparing the 105kbps file to the 112kbps Opus file, and if what you said is true, is probably the case when comparing the 105kbps file to a 106kbps Opus file.
I see. Because you found that visualization interesting, but I don't. The developers may even think they are extremely boring. For example if you also read other info from the developers like this:
https://youtu.be/iaAD71h9gDU?t=896

Quote
In response to what seemed to be one of the prime focuses of your first comment's opposition to what I shared in my first comment, when I said, "What this has convinced me of at the very least, is that 128kbps Opus is probably a safe conversion number to avoid such obvious distortion." The key parts are "convinced me", as opposed to me attempting to convince anyone else (something it seems you may have thought I was doing based on what you said), and "probably", as in there is uncertainty. Me being convinced that something is likely, does not mean I'm incapable of changing my mind if evidence to the contrary were to be presented. Basically, while 112kbps (and as low as 106kbps according to your findings; I haven't tried lower than 112kbps) was enough in this case to remedy the issue, 128kbps may (but might not in perhaps very rare cases) provide enough of a safety net to prevent similar extreme distortion issues in most or all cases, but further testing would be needed with many other samples to even come close to saying this is the case in something like a 99.99%+ range of samples that could be examined.
Just a disclaimer for myself, my tests are not used to convince anyone about what you mentioned, not my intent at all. Not that I wanted to disagree your opinions.

Quote
Btw, I think your title would have been a little clearer if you'd said 105kbps instead, because I don't think people usually refer to the end result bitrate that the file ends up at after conversion, they refer to the chosen Opus bitrate it was converted at. Is that wrong? What does that 231kbps in this case indicate anyways, and for all other audio files? Is it the highest bitrate at any point/s in the song, and all other parts of the song will vary somewhere at or below 231kbps? Or is it something else, perhaps an average bitrate? I'd assume not the latter (an average) since that seems to me like it may be a less useful number, though there's a good chance I don't understand why it would be useful, if that does indicate the average. I would have been very surprised if you'd converted the files at 231kbps and it has this sort of distortion. The first person to respond to you in this topic also seemed to indicate your title was a bit misleading, though I imagine it is unintentionally so.
If you see the attached wma archive in reply #2, the 90 and 98 numbers have nothing to do with bitrate at all, 100 means lossless as wma also has a lossless mode.

Another example:
https://hydrogenaud.io/index.php?topic=39970.0
"insane" means 320kbps CBR, so the file is actually 320kbps. In reply #7
https://hydrogenaud.io/index.php?topic=39970.msg351981#msg351981
I couldn't even remember what bitrates were used in "lame xtreme, vorbis q7, mpc xtreme" for that file. If I need to know the actual bitrates I would need to know which encoders and which versions I had used in the year of 2005. On the contrary, does it make sense to say the opus file is really 105kbps?

Re: Nontransparent example at 231kbps

Reply #10
So what was the point of the video, that they can go into great detail that goes far beyond the at least to me interesting fact that when you go from 106kbps to 105kbps with this specific sample, it even shows up on the visualizer in a very obvious way, and the differences continue to display in that same way well above and below those numbers? Is your goal to try to make me feel stupid so I'll shut up? Sorry to say, all I've felt so far is that you're being overly pedantic for no good reason, and seemingly trying to be offensive in a somewhat subtle way because you think that'll make me feel defeated or something, and stop responding.

And things don't have to be super complicated to be "interesting", it was a fun little thing I thought I'd share as a side note in addition to confirming your findings as to the presence of the extreme audio distortion, only at various other levels of conversion instead of 105kbps alone. Was it so wrong of me to include an opinion that I never attempted to say was your own, and even put a disclaimer at the bottom to convey I know that I probably don't know enough about a lot of this to have any sense of certainty, but my initial feeling was and still is that it is probably correct? Am I not allowed to add to the discussion by branching out a little bit with things related I think intimately with the topic, even before I know that you don't want me to branch out? You've made it into a big deal for no reason this whole time, as if there's something terribly wrong with what I shared and I should feel bad or dumb. It's cool to me because you can easily distinguish visually which files in these samples do and do not have the distortion with apparently a threshold of only a single kbps difference between them. I don't understand what problem you have with this, other than you personally don't care, and feel the need to repeat this a bunch of times as if I didn't get it the first time. If you'd never gotten caught up on this point, it would have ended there.

In part I was curious if there was something about that particular bitrate that caused the distortion you were claiming existed (I wasn't sure if such a thing was possible, that maybe it would not have the distortion at a lower bitrate for some reason for example), so I decided to try a variety and see what the results were. Am I not allowed to branch out in the slightest from whatever particulars you're choosing to focus on, even if it all relates to the topic and its contents? And I'd not at all be surprised if the developers of Opus could use this information (assuming they're not already aware of it and attempting to fix such issues, or it may be a low priority issue that has a list of others they want to deal with before it, or perhaps they simply can't fix it, or they haven't yet found a way to do it without breaking other things), both what I've shared and the contents of the topic as a whole, to help improve it further. If you can't see that as even a possibility, I doubt even an expert who understands what I'm trying to say can convince you (of course this is a theoretical situation I'm describing; I'd have to share it with such experts and then share their responses if I were to receive any), given your responses so far.

As far as what you said at the end, all I know is I was making my own conversions to make sure you didn't mess up somewhere, from the "toneClick.wav" file, which I believe is what you said we should compare with the "105kbps toneClick.opus" file.

If you think you know so much more than me, which you very well may when it comes to these issues, how about you show a little respect, patience and humility? Do you treat everyone who isn't well-versed in such topics this way?

I wasn't aware I'm not allowed to share things I find interesting (even if the visualizer thing was only a small side note I found neat) related to a topic because the topic creator might not. At the same time I don't know if they will appreciate it until I do it, so I guess I have to be clairvoyant too, or risk a repeat of this situation with someone who thinks similarly to you, even if that may be a relative rarity as far as I know (the number of people in the world who think similarly to you). Very few people have responded to things of this nature I've written like you have, that I can recall.

Edit: I thought I should add that it should be pretty obvious we're talking about a file from a .wav that has been most likely recently converted to Opus, right? You (or possibly someone else I guess) even wrote it on the file name that it is a 105kbps file, so I don't understand why you would say 231kbps in the title instead in spite of what you wrote in your last response. Even the 1st person to respond to you seemed a little confused by your title. I could be wrong in some way/s but my assumption at the moment is that you chose poorly when you said 231kbps in the title, given the circumstances we're actually dealing with here, and not your years old file hypothetical scenario, where yes you can't be expected to remember, but in that case you would be expected to make clear what that 231kbps number is referring to, no?

Re: Nontransparent example at 231kbps

Reply #11
So what was the point of the video, that they can go into great detail that goes far beyond the at least to me interesting fact that when you go from 106kbps to 105kbps with this specific sample, it even shows up on the visualizer in a very obvious way, and the differences continue to display in that same way well above and below those numbers? Is your goal to try to make me feel stupid so I'll shut up? Sorry to say, all I've felt so far is that you're being overly pedantic for no good reason, and seemingly trying to be offensive in a somewhat subtle way because you think that'll make me feel defeated or something, and stop responding.
Think in reverse. If you regard yourself as "layman" and "no expert", but can also easily see the things in that visualizer for these simple test files, then would it be unexpected for the developers? If you think that I was trying to make you look stupid, then I also think your repeated emphasis on this visualizer thing is also a sort of humiliation to the effort and knowledge of the developers. If you deny this, then don't say the same thing to me.
Quote
And things don't have to be super complicated to be "interesting", it was a fun little thing I thought I'd share as a side note in addition to confirming your findings as to the presence of the extreme audio distortion, only at various other levels of conversion instead of 105kbps alone. Was it so wrong of me to include an opinion that I never attempted to say was your own, and even put a disclaimer at the bottom to convey I know that I probably don't know enough about a lot of this to have any sense of certainty, but my initial feeling was and still is that it is probably correct? Am I not allowed to add to the discussion by branching out a little bit with things related I think intimately with the topic, even before I know that you don't want me to branch out? You've made it into a big deal for no reason this whole time, as if there's something terribly wrong with what I shared and I should feel bad or dumb. It's cool to me because you can easily distinguish visually which files in these samples do and do not have the distortion with apparently a threshold of only a single kbps difference between them. I don't understand what problem you have with this, other than you personally don't care, and feel the need to repeat this a bunch of times as if I didn't get it the first time. If you'd never gotten caught up on this point, it would have ended there.
You said:
I never attempted to say was your own
...then "convey" something.

In reverse, did I say the things below? Are you trying frame me talked about something like this?
as if there's something terribly wrong with what I shared and I should feel bad or dumb.

Then...
It's cool to me because you can easily distinguish visually which files in these samples do and do not have the distortion with apparently a threshold of only a single kbps difference between them.
Yet another example of what you thought I was thinking and trying to do. You should actually try to encode the file with 105 and 106kbps settings and ABX them. Perhaps you can also easily tell them apart as well, assume we are using the same encoder and that GUI slider. I did the ABX test with ears, not "visually". By no means the 105kbps vs 106kbps thing made me "cool". It is just a brute force approach that I ABXed the files in 1kbps step but what I heard was a sudden jump from 105 to 106kbps. Just the same way I was not trying to convince anyone about what settings are transparent. Again, think in reverse. It is also possible that 106kbps is not transparent to you or someone else, it is just my result.

Quote
Am I not allowed to branch out in the slightest from whatever particulars you're choosing to focus on, even if it all relates to the topic and its contents? And I'd not at all be surprised if the developers of Opus could use this information (assuming they're not already aware of it and attempting to fix such issues, or it may be a low priority issue that has a list of others they want to deal with before it, or perhaps they simply can't fix it, or they haven't yet found a way to do it without breaking other things), both what I've shared and the contents of the topic as a whole, to help improve it further. If you can't see that as even a possibility, I doubt even an expert who understands what I'm trying to say can convince you (of course this is a theoretical situation I'm describing; I'd have to share it with such experts and then share their responses if I were to receive any), given your responses so far.
The presenter in the video I posted is a member of this forum, a developer of Opus. I am not a developer so it is useless to convince me. If you want to use my example to convince them then it is really up to you. Just another disclaimer for myself: I was not going to use this example to convince the developers to fix something, not that I am saying you are wrong, dumb and something like that.

Quote
If you think you know so much more than me, which you very well may when it comes to these issues, how about you show a little respect, patience and humility? Do you treat everyone who isn't well-versed in such topics this way?

I wasn't aware I'm not allowed to share things I find interesting (even if the visualizer thing was only a small side note I found neat) related to a topic because the topic creator might not. At the same time I don't know if they will appreciate it until I do it, so I guess I have to be clairvoyant too, or risk a repeat of this situation with someone who thinks similarly to you, even if that may be a relative rarity as far as I know (the number of people in the world who think similarly to you). Very few people have responded to things of this nature I've written like you have, that I can recall.
I am not a staff member and I cannot disallow you to do something. You can read more old posts about the approach of using graphs or other form of visualization to explain something about hearing on this forum. New members are not disallowed to read old threads. Then perhaps you may think in a different way, or may not.

Quote
Edit: I thought I should add that it should be pretty obvious we're talking about a file from a .wav that has been most likely recently converted to Opus, right? You (or possibly someone else I guess) even wrote it on the file name that it is a 105kbps file, so I don't understand why you would say 231kbps in the title instead in spite of what you wrote in your last response. Even the 1st person to respond to you seemed a little confused by your title. I could be wrong in some way/s but my assumption at the moment is that you chose poorly when you said 231kbps in the title, given the circumstances we're actually dealing with here, and not your years old file hypothetical scenario, where yes you can't be expected to remember, but in that case you would be expected to make clear what that 231kbps number is referring to, no?
The opus file with file name 105kbps and 231 actual kbps in this 2021 thread was initially named by me, to indicate 105kbps was the setting of the file, not the actual bitrate of the file, even foobar shows the actual bitrate rather than the settings to create the file, like the attached screenshot shows, it does not show 105kbps If you disagree that 231 is the actual bitrate, feel free to report it as a bug.  105kbps was mentioned so that others can encode the file with that setting in order to produce the same file if they want to encode the file themselves. If I did not include the encoding settings then others may need to figure out the actual setting to create the file.

At the end, I am not a native speaker, if my meanings are unclear, ask for clarification, don't try to guess or assume my motivation, and accuse me of anything. Kind of a pain to reply in such a long way, looking up dictionaries and such.

Re: Nontransparent example at 231kbps

Reply #12
Think in reverse. If you regard yourself as "layman" and "no expert", but can also easily see the things in that visualizer for these simple test files, then would it be unexpected for the developers? If you think that I was trying to make you look stupid, then I also think your repeated emphasis on this visualizer thing is also a sort of humiliation to the effort and knowledge of the developers. If you deny this, then don't say the same thing to me.
I was not making any sort of judgement or insinuating anyone else would not necessarily notice what I noticed if they were to examine the files and issue you brought to the forum's attention. I just wanted to share what I found after I did my listening tests and thought it was a bit interesting.
You said:
I never attempted to say was your own
...then "convey" something.
I don't understand what you're trying to say here. I think I've thus far conveyed many things, including in that portion of what I wrote that you quoted, and afterwards extracted a small part of that you chose to focus on, followed by, '...then "convey" something.'
In reverse, did I say the things below? Are you trying frame me talked about something like this?
as if there's something terribly wrong with what I shared and I should feel bad or dumb.
No I did not say you said those things outright, and I'm not attempting to frame you. I did have a sense that your responses may have had an underlying intent to make me feel that way, but perhaps that is not the case.
Then...
It's cool to me because you can easily distinguish visually which files in these samples do and do not have the distortion with apparently a threshold of only a single kbps difference between them.
Yet another example of what you thought I was thinking and trying to do. You should actually try to encode the file with 105 and 106kbps settings and ABX them. Perhaps you can also easily tell them apart as well, assume we are using the same encoder and that GUI slider. I did the ABX test with ears, not "visually". By no means the 105kbps vs 106kbps thing made me "cool". It is just a brute force approach that I ABXed the files in 1kbps step but what I heard was a sudden jump from 105 to 106kbps. Just the same way I was not trying to convince anyone about what settings are transparent. Again, think in reverse. It is also possible that 106kbps is not transparent to you or someone else, it is just my result.
That was not an example of what I thought you were thinking and trying to do. It was me saying a part of why I thought what I saw with the visualizer was neat, or "cool", that it was in fact only doing what I described based on whether the files contained the distortion you brought to our attention or not. This is just again sharing part of why I even bothered mentioning the visualizer thing in the first place. I believe I've said this several times, I started with doing listening tests, and towards the end noticed the visualizer did what I described based on whether the easily heard distortion was present in each file or not. Me noticing the visualizer thing came after I did the audio listening tests, not before. I also said earlier that I did an ABX test comparing 105kbps to 112kbps, and I was able to on the first try get a 25 out of 25 correct in not much time. I also said that I believe you that the 106kbps file does not contain the distortion, but I haven't tested it myself.
The presenter in the video I posted is a member of this forum, a developer of Opus. I am not a developer so it is useless to convince me. If you want to use my example to convince them then it is really up to you. Just another disclaimer for myself: I was not going to use this example to convince the developers to fix something, not that I am saying you are wrong, dumb and something like that.
I said this earlier a couple times I think, but it is not just what you shared that I was thinking could be potentially useful to the developers, but probably a mixture of what everyone shared. They might think it's totally irrelevant even if I went into detail explaining what I thought about it, and had a back and forth with them. That would be fine with me, especially if I got a reasonable explanation as to why they thought that was the case. Though I might get different responses from different developers (not sure how many people work on it), some perhaps showing interest where others would not.
I am not a staff member and I cannot disallow you to do something. You can read more old posts about the approach of using graphs or other form of visualization to explain something about hearing on this forum. New members are not disallowed to read old threads. Then perhaps you may think in a different way, or may not.
I'm not sure if the exact (or at least similar enough) things I was interested in and pointed out in this topic initially have been discussed while dealing with a similar sample elsewhere on this forum. If I was interested in pursuing further information related to those issues, I might have to start my own topic, but I'm not sure if I care enough about the specifics of what I brought up here to do that. I sort of assumed I would be satiated by whatever replies I might get in this topic and move on, but in the end I'm still sort of where I started at the first reply I wrote here, in terms me feeling any sense of progress or further understanding relating to what I shared. Plus it would be sort of recycling portions of this topic by pointing to the files you provided as the basis for what would be spoken about. I'm not sure if there's a rule or rules against that sort of thing on this forum.
The opus file with file name 105kbps and 231 actual kbps in this 2021 thread was initially named by me, to indicate 105kbps was the setting of the file, not the actual bitrate of the file, even foobar shows the actual bitrate rather than the settings to create the file, like the attached screenshot shows, it does not show 105kbps If you disagree that 231 is the actual bitrate, feel free to report it as a bug.  105kbps was mentioned so that others can encode the file with that setting in order to produce the same file if they want to encode the file themselves. If I did not include the encoding settings then others may need to figure out the actual setting to create the file.
I do not think it is a bug, but I do think knowing the number you used to convert the file is probably more relevant than knowing the end result bitrate that the file displays when you highlight it in Foobar2000 for example. I could be wrong, but I think saying 105kbps in the title of this thread may be considered more useful information. If I convert the FLAC version of an album to 160kbps or 192kbps Opus for example, I personally put which number I used in the title of the album, generally at the end like this, "[160 Opus]" or, "[192 Opus]". This way there is no confusion in the future about which version of an album is which, or at what bitrate it was converted, in case I ever need that information for any reason.
At the end, I am not a native speaker, if my meanings are unclear, ask for clarification, don't try to guess or assume my motivation, and accuse me of anything. Kind of a pain to reply in such a long way, looking up dictionaries and such.
I thought this might be the case, based on some of the earlier replies, I don't mean to make things unnecessarily difficult for you. I figured since it had been about 5 days since the last post in this topic, it wasn't as though I were interrupting an ongoing conversation if I shared what I did starting with my first reply. I first read this topic around when you initially posted it, before it received the first reply from another forum user. I found what you shared interesting, and today decided to do a little of my own experimentation, and thought among other things maybe what I shared would be appreciated by someone who ended up reading this thread in the future, even if in the end you personally didn't.

Re: Nontransparent example at 231kbps

Reply #13
This Is why I switched from 160kbps to 192kbps Musepack, On highly tonal Ambient music Opus will be 180 ~ 280kbps while any other VBR codec will be 64 ~ 144kbps.
Got locked out on a password i didn't remember. :/

Re: Nontransparent example at 231kbps

Reply #14
This Is why I switched from 160kbps to 192kbps Musepack, On highly tonal Ambient music Opus will be 180 ~ 280kbps while any other VBR codec will be 64 ~ 144kbps.
In the same vein I left the thread alone for a few days and see what would show up, and this sort of reply is a normal one: comment about what types of signal or music would inflate the bitrate of Opus in order to improve or achieve transparency, and to what extent, rather than other irrelevant things like spectrograms or personal preference of using encoding settings to name their albums. In this case would I also need to include the version of the Opus encoder as well? Because different versions of encoders with the same settings could yield different encoded bitrates, regardless of the differences are audible or not, doing this would make the file names unnecessarily long. These details are stored in file metadata anyway.

BTW, by reading some of your posts I also found another relevant thread:
https://hydrogenaud.io/index.php?topic=120007.75

Re: Nontransparent example at 231kbps

Reply #15
If different versions yield different encoded bitrates, then how is either number more useful in your eyes, especially if you don't provide the version you used? In any case, we don't know for certain what version you used, or what the number you ended up giving came from, it's just an arbitrary number that we're not sure how to replicate because the results could differ based on the version we use. Unless there's something I'm not understanding, which may be the case. You already added the number to title of the file in question, so I'm not sure what your point is. No you don't have to add it to every single file you ever create, nor do you have to add it to the title of albums if you don't want to, but this is only one file we're looking at here, and you already did it.

I'm new to using Opus. Decided the other day instead of putting [Opus 160] at the end of every album title, I'd put all my albums into a subfolder of my main music folder called [Opus 160]. Within that same music folder I have another folder called [FLAC], and another one for my old files called [MP3]. Before I was almost only working with MP3s [a few FLACs as exceptions] so I didn't need separate format folders. Maybe I won't know exactly what version of Opus was used when I converted my music from FLACs in the future, but if people convert at Opus 160 with a FLAC as their starting point for the same file, and they end up with a slightly different bitrate, they can probably tell from there that I must have used a different version. Which again, makes saying Opus 160 seem like the most useful number I could give, since if they have other versions available, they could if they wish to, replicate the file exactly by trying different versions. It's probably the most helpful number for people to provide, am I wrong? In the end not a big deal. It appears to me you made a small error in your title that makes things slightly more confusing than needed, but not something that's difficult to sort out since the file in the archive you provided had the needed information in the title.

That whole thing about your choice of title, was again just a small side note that you're choosing to focus on. Like I said, even the first person to reply to you seemed a bit confused.
Quote
The Opus file you joined in your 7z archives is named "105kbps" and the output bitrate is 231 kbps as you mention it in the title. Correct me if I'm wrong, but you probably set Opus to 105 kbps. As Opus usually use much more bit with highly tonal sample, you get a very high bitrate on this short piece of sound. In other words you find an artifact with opus -105 and not with opus -231. That makes a big difference.
I would have appreciated if your first reply to me was "normal", instead of pretty much as far as I can tell, all of your replies from the very first sentence of your first reply to me, being fairly insulting for no good reason. Not saying the entirety of all of your replies were insulting, but portions of them that colored the rest of the contents in the same light. There was nothing wrong with what I shared as far as I'm aware. If you don't agree, that's fine, but you haven't provided any reason for me to think you're right.

It feels like you kinda dodged my previous reply by the way.

One last thing, if that link you left was for me, while I appreciate the what I hope is a friendly gesture, I'm pretty sure I found and read it before I created my other topic. It did not contain enough information to feel like I knew for certain whether 160 or 192 Opus would be preferable, and as I said in my topic I believe, I've read probably most of the information I could find related to my question going back to 2011 (obviously information related to newer versions of Opus is what I should be focusing on since the quality has improved greatly). I've been waiting for replies to roll in for a little while before I go back to it and give probably everyone a reply in one large comment. I read everyone's replies there soon after they were left.


Re: Nontransparent example at 231kbps

Reply #16
You already added the number to title of the file in question, so I'm not sure what your point is
Simple. To reduce the chance of people asking how to create the same file, in case they are not aware about the stored metadata. Personally I don't do this in my collection. I just use album name and artist to name my things.

The rest of your reply about what you think about me, I can't change how you think anyway, and as you mentioned earlier, I can't disallow you to do anything, so I think I can end my reply here, to keep it short.

Re: Nontransparent example at 231kbps

Reply #17
This Is why I switched from 160kbps to 192kbps Musepack, On highly tonal Ambient music Opus will be 180 ~ 280kbps while any other VBR codec will be 64 ~ 144kbps.
In the same vein I left the thread alone for a few days and see what would show up, and this sort of reply is a normal one: comment about what types of signal or music would inflate the bitrate of Opus in order to improve or achieve transparency, and to what extent, rather than other irrelevant things like spectrograms or personal preference of using encoding settings to name their albums. In this case would I also need to include the version of the Opus encoder as well? Because different versions of encoders with the same settings could yield different encoded bitrates, regardless of the differences are audible or not, doing this would make the file names unnecessarily long. These details are stored in file metadata anyway.

BTW, by reading some of your posts I also found another relevant thread:
https://hydrogenaud.io/index.php?topic=120007.75

Vorbis had the same problems with bloat on samples that Lame MP3 is transparent at V5. When I tried some tonal/noisy samples at Q6 = 245kbps, Q8 = 380 ~ 540kbps, Opus does the same --128kbps = 185kbps, --192kbps = 300kbps. But AAC/MP3/MPC = <170kbps without any issues.

Classical/acoustic is worst with Opus, I have dark ambient albums with acoustic instruments. The average bit rate will be 220 ~ 285kbps while on AAC/MP3/MPC they stay within 80 ~ 160kbps. The time the 3 up the bit rate(over 200kbps) is when it nothing but hard transients, Loud noises and ambient noises that fight each other. I think it CVBR like stops it from being 384kbps on a synthy ambient song. It is CVBR since I found a killer sample at 160kbps that could've been avoided if it targeted 400kbps instead of being 159kbps, Which what MPC does to avoid having shifting settings too much.

Oddly xHE AAC doesn't have those bit rate bloat issues at 100kbps & has a much better CVBR system.
Got locked out on a password i didn't remember. :/

Re: Nontransparent example at 231kbps

Reply #18
Vorbis had the same problems with bloat on samples that Lame MP3 is transparent at V5. When I tried some tonal/noisy samples at Q6 = 245kbps, Q8 = 380 ~ 540kbps, Opus does the same --128kbps = 185kbps, --192kbps = 300kbps. But AAC/MP3/MPC = <170kbps without any issues.

Classical/acoustic is worst with Opus, I have dark ambient albums with acoustic instruments. The average bit rate will be 220 ~ 285kbps while on AAC/MP3/MPC they stay within 80 ~ 160kbps. The time the 3 up the bit rate(over 200kbps) is when it nothing but hard transients, Loud noises and ambient noises that fight each other. I think it CVBR like stops it from being 384kbps on a synthy ambient song. It is CVBR since I found a killer sample at 160kbps that could've been avoided if it targeted 400kbps instead of being 159kbps, Which what MPC does to avoid having shifting settings too much.

Oddly xHE AAC doesn't have those bit rate bloat issues at 100kbps & has a much better CVBR system.
Apart from being tonal, the tones in left and right channels are also slightly different in my test sample as well. When bitrate is not high enough, the encoder combined the frequencies as mono, which caused beating and widened the side lobe and caused more damage. Quite a malicious attempt I do admit. Interestingly @Gravitator used my test sample to trip exhale, I did not expect that.
https://hydrogenaud.io/index.php?topic=118888.msg997843#msg997843

People with good ears can try the following sample from a game music OST as well, tonal and at high frequencies:
https://hydrogenaud.io/index.php?topic=120491.msg993500#msg993500

Re: Nontransparent example at 231kbps

Reply #19
Quite a malicious attempt I do admit. Interestingly @Gravitator used my test sample to trip exhale, I did not expect that.
https://hydrogenaud.io/index.php?topic=118888.msg997843#msg997843
For the record, that issue in exhale was a kind of bug (bad design of the automatic audio bandwidth detection) and should be fixed in newer releases (1.1.6 and later). Very useful test sample for such issues, by the way, so thanks.

Chris
If I don't reply to your reply, it means I agree with you.

Re: Nontransparent example at 231kbps

Reply #20
Vorbis had the same problems with bloat on samples that Lame MP3 is transparent at V5. When I tried some tonal/noisy samples at Q6 = 245kbps, Q8 = 380 ~ 540kbps, Opus does the same --128kbps = 185kbps, --192kbps = 300kbps. But AAC/MP3/MPC = <170kbps without any issues.

Classical/acoustic is worst with Opus, I have dark ambient albums with acoustic instruments. The average bit rate will be 220 ~ 285kbps while on AAC/MP3/MPC they stay within 80 ~ 160kbps. The time the 3 up the bit rate(over 200kbps) is when it nothing but hard transients, Loud noises and ambient noises that fight each other. I think it CVBR like stops it from being 384kbps on a synthy ambient song. It is CVBR since I found a killer sample at 160kbps that could've been avoided if it targeted 400kbps instead of being 159kbps, Which what MPC does to avoid having shifting settings too much.

Oddly xHE AAC doesn't have those bit rate bloat issues at 100kbps & has a much better CVBR system.
Apart from being tonal, the tones in left and right channels are also slightly different in my test sample as well. When bitrate is not high enough, the encoder combined the frequencies as mono, which caused beating and widened the side lobe and caused more damage. Quite a malicious attempt I do admit. Interestingly @Gravitator used my test sample to trip exhale, I did not expect that.
https://hydrogenaud.io/index.php?topic=118888.msg997843#msg997843

People with good ears can try the following sample from a game music OST as well, tonal and at high frequencies:
https://hydrogenaud.io/index.php?topic=120491.msg993500#msg993500

Most codecs had issues with Stereo audio under 224kbps, Vorbis was the worst for turning anything into mono or semi mono mess. I gave up ABX'ing them when 96kbps AAC, V5 Lame, 128kbps were transparent while Vorbis needed 144kbps to match them. Vorbis/Opus seem to can't handle music that suddenly shifts into highly tonal electronic with hard attacks and tonal/noise either cause the bit rate too low or the encoder is confused.

I've got a album the boron chamber that needs Q9 Vorbis cause the end part of it at 192kbps VBR is bit rate starved, 400kbps is needed to fix it. 


Got locked out on a password i didn't remember. :/

 
SimplePortal 1.0.0 RC1 © 2008-2021