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?

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.

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?

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.

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.

QUOTE (wswartzendruber @ Mar 25 2013, 18:23)

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?

QUOTE (wswartzendruber @ Mar 25 2013, 18:23)

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.

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 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?

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.

QUOTE (wswartzendruber @ Mar 25 2013, 19:44)

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 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.

QUOTE (jmvalin @ Mar 25 2013, 18:55)

QUOTE (wswartzendruber @ Mar 25 2013, 19:44)

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?

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!

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

QUOTE ("jmvalin")

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!

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.

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.

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.

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.