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: Lossless Extensions for Opus (Backwards Compatible) (Read 69627 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Lossless Extensions for Opus (Backwards Compatible)

Reply #50
Lossless extensions to Opus would be completely pointless IMO except maybe if the resulting (lossless extensions + lossy) file would be smaller than other widely supported lossless formats.

Lossless Extensions for Opus (Backwards Compatible)

Reply #51
Yeah, I hear you there.  I've contacted the OptimFROG developer to see if he's interested, but haven't heard anything back.

Lossless Extensions for Opus (Backwards Compatible)

Reply #52
I have heard back from the OptimFROG developer.  He has expressed great interest in the idea and we are corresponding.

Lossless Extensions for Opus (Backwards Compatible)

Reply #53
When I came up with this idea, my primary use case was movies.

I still don't get this. Sorry, I haven't followed this thread much and might have missed something, but: How do movies benefit from lossless and backward compatibility to Opus at the same time? Only Blu-Ray does lossless audio beside video, I think, and if you're going for Hi-res video, why not use FLAC from the start? It's much more widely supported than Opus on mobile and media-Center devices right now (and probably also in the next few months or even years, industry can be quite slow).

Second question for clarification: so now you're trying to get Florin to develop a coding scheme for the lossless Opus-extension layer based on OptimFrog?

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

Lossless Extensions for Opus (Backwards Compatible)

Reply #54
I solicited Florin for interest in the project and pointed him to this thread.  He has responded with a very positive attitude and some ideas of his own.  We have different approaches on the details (API, where certain information is stored, etc...), so I am probably going to be making a lot of concessions.  I look forward to his valuable input on my ideas, and most importantly, his expertise with lossless compression.  If this project becomes successful, it will be because of him.

EDIT:  The initial use case was for movies.  He and I are talking about other sample rates and need to work that out before I make anymore statements.

Lossless Extensions for Opus (Backwards Compatible)

Reply #55
I have heard back from the OptimFROG developer.  He has expressed great interest in the idea and we are corresponding.
Is he aware that the developers of Opus consider this to be a bad idea and do not intend to support it and will not be maintaining a bit exact decoder at this time? Or that the resulting streams are not losslessly seekable?

Lossless Extensions for Opus (Backwards Compatible)

Reply #56
I have heard back from the OptimFROG developer.  He has expressed great interest in the idea and we are corresponding.
Is he aware that the developers of Opus consider this to be a bad idea and do not intend to support it and will not be maintaining a bit exact decoder at this time? Or that the resulting streams are not losslessly seekable?

He struck me as very unimpressed with the criticisms provided in this thread.  With that said, I suspect he doesn't have a lot of interest in whether or not the Opus developers agree.  What fundamentally matters is that Opus is properly specified and those specifics allow for extension packets.  I don't see how our use of those extension packets is really any of their concern, given that we make our extension formatting readily identifiable (so as not to throw off future decoders that use other extensions).

As far as bit-exact decoding goes, he and I currently agree that using an existing fixed point implementation is the way to go.  This would likely be used to generate the deltas and later to decode the Opus core stream.

He has not mentioned lossless seeking, but we may be able to use the extension packets to help the decoder out.

I'm still waiting to hear back from him.  It's possible he has lost interest in the project.  If this is the case, I will continue alone.

Lossless Extensions for Opus (Backwards Compatible)

Reply #57
He struck me as very unimpressed with the criticisms provided in this thread.  With that said, I suspect he doesn't have a lot of interest in whether or not the Opus developers agree.  What fundamentally matters is that Opus is properly specified and those specifics allow for extension packets.  I don't see how our use of those extension packets is really any of their concern, given that we make our extension formatting readily identifiable (so as not to throw off future decoders that use other extensions).


Readily identifiable assuming people actually know about your stuff -- which they won't. The current spec specifically says that the padding *MUST* be set to zero. This is done intentionally, so that any future extension has to be agreed on in the IETF WG to avoid any issue. What you're suggesting is essentially a rogue, incompatible extension that disregards the standard process.

As far as bit-exact decoding goes, he and I currently agree that using an existing fixed point implementation is the way to go.  This would likely be used to generate the deltas and later to decode the Opus core stream.


You're aware that the output of the fided-point decoder *will* change in the future, right?

I'm still waiting to hear back from him.  It's possible he has lost interest in the project.  If this is the case, I will continue alone.


Fortunately, that is indeed likely.

Lossless Extensions for Opus (Backwards Compatible)

Reply #58
As far as bit-exact decoding goes, he and I currently agree that using an existing fixed point implementation is the way to go.  This would likely be used to generate the deltas and later to decode the Opus core stream.


Ok, help me out here.

The whole idea of doing this hack (and don't get me wrong, "hack" isn't a bad word), IIRC, was so that it was a playable OPUS stream with padding which would allow you to make it lossless if you wanted.  OPUS was chosen over existing solutions because it was "not proprietary".

Yet you've sought out the help of a coder who has not released the code to his proprietary codec.  A codec you're going to put in the padding in violation of the OPUS spec.  A codec which likely is patent encumbered just not tested because its ripple in the pond is so small.

And not just any OPUS decoder will work with this stream.  We'll need to use a specific OPUS decoder which isn't even the official code.

I'm not sure we agree on what "proprietary" means.
Creature of habit.

Lossless Extensions for Opus (Backwards Compatible)

Reply #59
I am no longer seeking to use Opus padding.  I now intend to have these extension packets violate constraint R5.  Per the RFC, doing so triggers the standardized decoder to ignore them because they are reserved for future extensions.

Florin's recent communication with me indicated that he's going to be far more open with his new stuff.  The issue of his work possibly being patented concerns me, though.  I had not thought of that.

And who says I have to update the fixed point decoder I choose to use?

Lossless Extensions for Opus (Backwards Compatible)

Reply #60
I am no longer seeking to use Opus padding.  I now intend to have these extension packets violate constraint R5.  Per the RFC, doing so triggers the standardized decoder to ignore them because they are reserved for future extensions.


Well, I wouldn't bet on that rule actually being widely followed.

And who says I have to update the fixed point decoder I choose to use?


Congratulations, you are now the proud maintainer of a fork of the entire Opus codebase. Best of luck in your new responsabilities.

Lossless Extensions for Opus (Backwards Compatible)

Reply #61
Florin's recent communication with me indicated that he's going to be far more open with his new stuff.


Those are oft-said words, less frequently acted upon.
The issue of his work possibly being patented concerns me, though.  I had not thought of that.



It doesn't really matter, you are unlikely to ever be a target of action.

Neither of those points of mine matter in the big picture.  Except that I'm trying to get you to think about your apparently contradictory views on "proprietary".
Creature of habit.

Lossless Extensions for Opus (Backwards Compatible)

Reply #62
I am no longer seeking to use Opus padding.  I now intend to have these extension packets violate constraint R5.  Per the RFC, doing so triggers the standardized decoder to ignore them because they are reserved for future extensions.


Well, I wouldn't bet on that rule actually being widely followed.

I've been thinking about that for a couple weeks.  Right now my plan is to declare a packet with no frames (violate R5) and then have the deltas compressed in "padding" for that packet.  So when I say I'm no longer using padding, I mean I'm not using padding in a packet with frames.  The deltas will be in what is essentially a code 3 packet with zero frames and lots of padding.  This increases my chances of a non-compliant decoder just going, "Durrrr, zero frames, now padding, uh...next..."  I've also thought of violating another R5 rule by declaring a padding size inconsistent with the total frame length and packet size.  I think that this second way is maybe not a good idea.

And who says I have to update the fixed point decoder I choose to use?


Congratulations, you are now the proud maintainer of a fork of the entire Opus codebase. Best of luck in your new responsabilities.

I need to retain the entire code base to keep the fixed-point decoder? 

Lossless Extensions for Opus (Backwards Compatible)

Reply #63
And who says I have to update the fixed point decoder I choose to use?


Congratulations, you are now the proud maintainer of a fork of the entire Opus codebase. Best of luck in your new responsabilities.

I need to retain the entire code base to keep the fixed-point decoder? 


Well, I was assuming you also wanted to have tweaks in the encoder to make it not use the many features that improve the perceptual quality while making the residual larger... Not to mention the mess of taking the encoder and decoder from different codebases (many functions are shared). Lots of fun!

 

Lossless Extensions for Opus (Backwards Compatible)

Reply #64
I wonder why you've chosen opus? Rather than a more widely implemented codec that supports 44.1kHz natively?

By the time you've finished, mp3's patents will probably have expired.

Not that mp3+FLAC in the way you're proposing it would be attractive.

Cheers,
David.

Lossless Extensions for Opus (Backwards Compatible)

Reply #65
MP3 stops at stereo.  Besides that, there is already mp3HD.  It works by storing the deltas as ID3v2 tags. 

Quote
Well, I was assuming you also wanted to have tweaks in the encoder to make it not use the many features that improve the perceptual quality while making the residual larger... Not to mention the mess of taking the encoder and decoder from different codebases (many functions are shared). Lots of fun!

That kind of thing might happen if I get a proof-of-concept working.

Lossless Extensions for Opus (Backwards Compatible)

Reply #66
MP3 stops at stereo.
http://en.wikipedia.org/wiki/MP3_Surround

Quote
Besides that, there is already mp3HD.  It works by storing the deltas as ID3v2 tags. 
I don’t see how mp3HD being implemented in a way that you find distasteful (as many people will find your attempt to kludge lossless into Opus) rules out your ability to develop a scheme you like more, thus making this not a very informative reply as to the reasoning behind your dismissal of MP3 as a base.

Lossless Extensions for Opus (Backwards Compatible)

Reply #67
First off, mp3 Surround (which I would hypothetically build on) is not open and I have no desire to extend it.  Second, if their best answer for mp3HD was to embed the deltas in freaking header metadata, that tells me the bitstream is fundamentally non-extendable.  Opus was designed to be extended from the beginning, similar to DTS.

Lossless Extensions for Opus (Backwards Compatible)

Reply #68
First off, mp3 Surround (which I would hypothetically build on) is not open


OptimFROG, the proprietary format on which you have hypothetically decided to build on is not open either.

Second, if their best answer for mp3HD was to embed the deltas in freaking header metadata, that tells me the bitstream is fundamentally non-extendable.


MP3 is a compression format, not a container.  If you want an extensible container, use one of the many that supports MP3, such as MP4 or MKV.

Lossless Extensions for Opus (Backwards Compatible)

Reply #69
MP3 is a compression format, not a container.  If you want an extensible container, use one of the many that supports MP3, such as MP4 or MKV.


Now that's just silly, saratoga.  If a container was an acceptable answer one could just put an OPUS stream and a FLAC stream in that!

/s
Creature of habit.

Lossless Extensions for Opus (Backwards Compatible)

Reply #70
Actually I suppose if the goal is to have this work on any old software device, the obvious format to use is AAC, since every AAC player in existence supports MP4 with >2 channels, and you can easily insert the lossless correction data into the MP4 file as a separate stream without breaking anything.

Lossless Extensions for Opus (Backwards Compatible)

Reply #71
I see that reiteration is necessary.

1. I have no desire to extend something that is not open and royalty-free.
2. Florin has stated his intention of having his new work be open.
3. AAC is not royalty free.
4. Packing Opus and FLAC together in the same container takes more space than I would like, and seems redundant.
5. I have lost contact with Florin, and an OptimFROG-derived codec for deltas may be out of the question.

Lossless Extensions for Opus (Backwards Compatible)

Reply #72
I see that reiteration is necessary.
1. I have no desire to extend something that is not open and royalty-free.


How do you reconcile this statement with all of the posts you made from Feb 28 onward detailing your plans to extend a format that was not open?

2. Florin has stated his intention of having his new work be open.


He told you he planned to open OptimFROG?

Lossless Extensions for Opus (Backwards Compatible)

Reply #73
1. I am not out to extend OptimFROG, I'm out to extend Opus.  If this succeeds, these streams will not be decodable by OptimFROG, but by Opus.  OptimFROG may be a catalyst.

2. He seems to have greatly improved OptimFROG and plans to make that standardized and open.  I don't know about royalties, though.  I'm also much more concerned about possible patent "infringement."

EDIT:  It would be neat if he would get back to me.  Even if just to tell me I'm a total idiot.

Lossless Extensions for Opus (Backwards Compatible)

Reply #74
I sent Florin one last email asking for input.  If I don't get a response within a week, I'm going on without him.

I'm not going to stop until I see for myself that this will not work well.