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: Opus 1.1a BABYEATER build (Read 29182 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Opus 1.1a BABYEATER build

Reply #25
Quote
what kind of problems did you hear?


It sounds intermitently and tinkling as compared with others. I think everybody can hear some kind of noise if listen carefully.



Opus 1.1a BABYEATER build

Reply #26
I think I've noticed a minor issue in the encoder, but I'm not familiar enough with the tech to understand exactly why it happens. See the attached files for an example. I created the sound a long time ago so it's not copyright in any way.

Sample 1: The 44.1kHz wav file shows some distortion in the output .opus file (and .wav file when decoded).

Sample 2: When the same original wav file from Sample 1 is first resampled to 48kHz using a different tool (Audacity), the encoded result sounds basically perfect, except for a small click at the beginning, but I suspect that's due to my player - the decoded wav output has no click.


Is this related to the resampler in the Opus encoder?


Edit: Updated attachment

Opus 1.1a BABYEATER build

Reply #27
Another sample making issues:
DWK Sample
A sweeping sound in the background occurs synchronical to the bassline. I haven't tested it with the latest git version, though, but with the one here from the topic.

Opus 1.1a BABYEATER build

Reply #28
I can't reproduce your problem on mainline builds. Haven't tried with the babyeater build.

jmvalin has asked that people now use mainstream pre-1.1 builds and not the babyeater build. The Babyeater builds were an experiment in variable frame sizes; jmvalin and NullC needed some feedback on their experiment, people responded, some major issues were found, and there's a good bit of work to be done before they ask people to test that again. In the meantime there are plenty of other innovations etc in the master builds that need more testing.

This again highlights the need for very visible instructions and warnings for prospective testers and an up-to-date link to builds (and possibly source snapshots/git revision numbers) the Opus devs would prefer people use for testing. I've proposed before that this be done with a sticky in the Opus subforum- indeed that's one of the main reasons I pushed for having a dedicated Opus subforum. When those instructions and warnings aren't very visible, we all have to keep correcting misconceptions. When people who want to help test don't know which builds to test, they may be wasting their time, and responding to their reports may waste developers' time. Simple steps to improve communication can go a long way to help.

Opus 1.1a BABYEATER build

Reply #29
The above post has been moved from the associated thread in Uploads.

Thanks for pointing out jmvalin’s request. It would have made sense for him or NullC to post that here, but better late and posted by someone else than never, I suppose. Should this thread be closed until further notice, in that case?

Opus 1.1a BABYEATER build

Reply #30
jmvalin has asked that people now use mainstream pre-1.1 builds and not the babyeater build. The Babyeater builds were an experiment in variable frame sizes; jmvalin and NullC needed some feedback on their experiment, people responded, some major issues were found, and there's a good bit of work to be done before they ask people to test that again. In the meantime there are plenty of other innovations etc in the master builds that need more testing.


Actually, I recommended that people stop testing babyeater, but testing of 1.1-alpha and git is still very appreciated. The more testing we get, the quicker we can get to a final 1.1 release. We're interested in cases where 1.1 performs poorly, but what's even more useful is when 1.1 performs worse than 1.0.x, i.e. regressions.

Opus 1.1a BABYEATER build

Reply #31
I can't reproduce your problem on mainline builds. Haven't tried with the babyeater build.

I can't spot it anymore either since I switched to Direct Sound as output, seems to be a problem with WASAPI (which I use in general) or my audio drivers, didn't take that possibility into account lol. Anyway, I'm very sorry for putting that "blinder", Opus is indeed fine on this one.
This again highlights the need for very visible instructions and warnings for prospective testers and an up-to-date link to builds (and possibly source snapshots/git revision numbers) the Opus devs would prefer people use for testing. I've proposed before that this be done with a sticky in the Opus subforum- indeed that's one of the main reasons I pushed for having a dedicated Opus subforum. When those instructions and warnings aren't very visible, we all have to keep correcting misconceptions. When people who want to help test don't know which builds to test, they may be wasting their time, and responding to their reports may waste developers' time. Simple steps to improve communication can go a long way to help.

Regularly updated builds would indeed be great, though.

Opus 1.1a BABYEATER build

Reply #32
The version 1.1a is the last testing build that works fine for me. 
Opus 1.1 alpha version (not BABYEATER)
In my opinion Opus 1.1a is already very good and there is still a room for improvements. But I think the development of a new video codec Daala should have a highest priority as bandwith savings are much higher for video.

Opus 1.1a BABYEATER build

Reply #33
Actually, I recommended that people stop testing babyeater, but testing of 1.1-alpha and git is still very appreciated.
I'm confused. By starting with 'Actually,' you give the impression that I said something false which you're correcting, but you apparently go on to repeat what I just said. Maybe by "pre-1.1" you thought I meant "1.0.x"? I meant "development versions leading up to 1.1," as could be seen from my mention of the innovations in git master.

Regularly updated builds would indeed be great, though.
Sure, it would, but that's not quite what I was asking for, and perhaps I didn't do well at making that clear.

Regardless of how frequent/up-to-date the builds are, the link needs to be up-to-date. In other words, whether they set up a Jenkins windows build artifact and prefer that testers use those bleeding edge builds or whether they only sporadically provide "blessed" builds for testers every few months, they need to communicate clearly about which builds prospective testers should use.

Right now, the most up-to-date advice on which build to test is quite frequently buried in some thread somewhere or stated in the (ephemeral, no public logs) IRC channel. In other words, it's effectively invisible to most people. This puts prospective testers, especially those on platforms like Windows where setting up a build environment takes knowledge and effort, at a real disadvantage. It is an unnecessary barrier, and it causes confusion, frustration, and useless bug reports.

 

Opus 1.1a BABYEATER build

Reply #34
Actually, I recommended that people stop testing babyeater, but testing of 1.1-alpha and git is still very appreciated.
I'm confused. By starting with 'Actually,' you give the impression that I said something false which you're correcting, but you apparently go on to repeat what I just said. Maybe by "pre-1.1" you thought I meant "1.0.x"? I meant "development versions leading up to 1.1," as could be seen from my mention of the innovations in git master.


Yeah, I thought you meant 1.0.x. Sorry for the confusion.