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: lossyWAV 1.1.0 Development Thread. (Read 186225 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

lossyWAV 1.1.0 Development Thread.

Reply #150 –
Quote from: collector on
Quote from: shadowking on

Your are kind off right. I still think lossywav can take on and beat Lame 320k at similar bitrates simply due to the mp3 native defect.

In bitrate/quality perhaps, but not in filesize. Average filesize of my testset Q1 lossyflacs is almost twice the size of my mp3 V1, let alone V4. DAP users won't like that.


No arguments there. I think the typical losswav user is:

- Experienced user wanting very high quality and predictable transcoding at half or less bitrate of lossless. Maybe this applies to a clueless user too.
- A more naive user want good enough Flac sound in his / her DAP saving themselves transcoding. They can use lower bitrates and still be very happy. They really should make correction files because normal codec @ 160..190k is similar quality to 260 k hybrid but they are much smaller.

lossyWAV 1.1.0 Development Thread.

Reply #151 –
Quote from: collector on
In bitrate/quality perhaps, but not in filesize.

Really?    For bitrate above 256, lossywav better then anybody lossy-codecs.

Code: [Select]
lame --preset insane - 9.502.369
lame --abr 280 - 8.653.434
lame -b 256 - 7.636.113

oggenc -b 270 - 7.961.898
oggenc -b 280 - 8.350.866

lossywav -q 0 / flac -5 -b 512 --keep-foreign-metadata - 8.087.723

It is an example, but I will make a test for 88 albums if you need.

lossyWAV 1.1.0 Development Thread.

Reply #152 –
Quote from: collector on
In bitrate/quality perhaps, but not in filesize. Average filesize of my testset Q1 lossyflacs is almost twice the size of my mp3 V1, let alone V4. DAP users won't like that.


filesize = duration*bitrate.

You've got a point with your reply, but the point itself is a bit out of place:

-V1 or -V4 are not CBR 320kbps ( just like the number 3 is not the number 5 ).
When someone uses such a high bitrate with mp3, the main reason is to get as high quality as possible, with a compatible-enough format. (i.e. not just "transparency")

The point of lossyWav origin was to couple it with the most supported lossless codec (or so was the pretention). Nowadays, lossywav not only works with FLAC, but with other lossless codecs, so possibly increasing the range of situations where it can be used.

Said that, what an user may want from a CBR 320kbps file, may more probably be achieved with lossywav -q 4 or -q 5, which is around 400~450kbps.
But 400~450kbps is the half of what the lossless file requires.

Personally, i see -q 0 and -q 1 as a way to give a lossless-like file at a reduced bitrate, with the added advantage that if the produced file sounds wrong, the quality setting can go up until it dissapears. (not like cbr 320)

lossyWAV 1.1.0 Development Thread.

Reply #153 –
Quote from: carpman on
I've lost touch a little. Am I right in thinking:
10 is pretty much the old -1
7.5 is pretty much the old -2
5 is pretty much the old -3

It's rather:
--extreme (-q 7.5) is old -1
--standard (-q 5.0) is old -2
--portable (-q 2.5) is old -3.
Quote from: carpman on
... I wouldn't go any lower than 2.5, especially since transparency is pretty much guaranteed with MP3 at lower bitrates, why would you choose a "mp3 replacement" (or whatever term you like) when LossyWAV, at sub 2.5 bitrates, is not as safe as MP3? ...

I feel like you for the lowest quality settings though due to the mp3 restrictions shadowking mentioned on occasion lossyWAV may yield the better quality even below 300 kbps.
The real benefits of lossyWAV start pretty much exactly where mp3 has its highest bitrate. So lossyWAV --portable drops in fine where mp3 quality stops.
Moreover with nowaday's DAPs capacities a bitrate of more than 300 kbps can be used without pain by more and more people.

But as is yours this is just my opinion towards a very low bitrate setting.
No matter that I wouldn't like to use a very low bitrate setting I wouldn't care however to have such a quality preset. Maybe it's just asthetics, but with 2 quality presets above --standard it would be nice IMO to have 2 below it. Maybe the lowest preset quality shouldn't be exactly -q 0 (though this would perfectly correspond to the -q setting / quality preset mapping we have so far). v1.0.1k --portable yields a bitrate of 362 kbps with my full length regular music test set. Maybe -q 1 (307 kbps) or -q 1.5 (327 kbps) may be an attractive candidate for the lowest preset quality. Both are quite a bit more attractive than --portable bitratewise, and quality even for problem samples is expected not to be annoying (at least for -q 1.5).

So I'd like to see a lowest quality preset, and my proposal is -q 1.5 for the incarnation. My proposal for the name is just '--low' (pretty much of an understatement at least for -q 1.5, but IMO this matches the quality scale of the other quality presets).

ADDED later:
It just comes to my mind that in a way lossyWAV has a BIG advantage over other lossy codecs: it is LOSSLESSLY FUTURE-SAFE.
Assume we use FLAC as the final codec. Assume in 10 years from now you can't play FLAC on your DAP. You then simply transcode to the then preferred lossless codec which is a lossless process.
Taking this into account it's ok IMO to call the lowest qualty preset (in case it's a little bit higher than -q 0) an 'mp3 alternative' - an alternative of comparable quality as very high bitrate mp3 but with this extra advantage of future-safety.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.1.0 Development Thread.

Reply #154 –
I'm sorry I didn't follow this thread as closely as I would have liked, but I've observed that LossyWAV 1.01k produces significantly higher bitrates at q0 than 1.01f, which had the lowest I've seen so far and which I was quite satisfied with.  Is there any possibly of remapping the quality scale such that that the low bitrate of 1.01f is reestablished at q0?  It seems a lot like I'm going up a whole quality scale (0 to 1 or the like) from f to k with the same settings...
Copy Restriction, Annulment, & Protection = C.R.A.P. -Supacon

lossyWAV 1.1.0 Development Thread.

Reply #155 –
I tried to encode "ginnungagap..." sample using lossyWAV 1.0.1k and various options.
For me, "-q 0 -m 5.333" sounds better than "-q 1" for that particular sample. Both results in 335 kbps bitrate.

lossyWAV 1.1.0 Development Thread.

Reply #156 –
Quote
' date='May 24 2008, 05:47' post='566920']
You've got a point with your reply, but the point itself is a bit out of place:
-V1 or -V4 are not CBR 320kbps ( just like the number 3 is not the number 5 ).
When someone uses such a high bitrate with mp3, the main reason is to get as high quality as possible, with a compatible-enough format. (i.e. not just "transparency")

V4 is not that high with 160 kbps. And I've seen numerous discussions about smaller filesizes for limited diskspace on mp3-DAPs. But I only interfered here because the lower q settin was proposed to be 'mp3' somewhere. Whether transcoding from a flac image to lower flac or to mp3 doesn't matter for me..

The names are only important to the non-technical users. Tweakers will test the various q-settings.

lossyWAV 1.1.0 Development Thread.

Reply #157 –
Quote from: lvqcl on
I tried to encode "ginnungagap..." sample using lossyWAV 1.0.1k and various options.
For me, "-q 0 -m 5.333" sounds better than "-q 1" for that particular sample. Both results in 335 kbps bitrate.

Sounds like there's hope for improving the very low bitrate settings.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.1.0 Development Thread.

Reply #158 –
BTW, Nick, thanks for changing the scale factor and for adding the --writelog.

All of a sudden redirecting stopped working for "lossywav --longhelp>>longhelp.txt" a few versions ago. 

lossyWAV 1.1.0 Development Thread.

Reply #159 –
... I am really perplex about people telling lossywav -q0 or -q1 is a viable alternative to  any modern lossy codec at VBR 256 or 320Kbps for any use ... first using 320Kbps instead of 256Kbps even for a paranoid user is always sub-optimal, no matter the modern lossy codec 256Kbps is always a better choice than 320Kbps, 320Kbps has always been the "my-bitrate-is-higher-than-yours-so-my-files-are-better-than-yours" setting of newbies, if there would be a 321Kbps setting these knowledge-less newbies would use it anyway.
So I wouldn't compare lossywav -q 0/-q 1 to lossy 320Kbps but to lossy 256Kbps.

Now comparing any modern lossy codec at 256Kbps with lossywav -q0, you compare, heavyly tested techniques (DCT), on files that are smaller & 99.9% transparent (& even when it's not transparent, it's listenable & only ABXable by people with golden ears on specific problems samples) ... with a technique that is still beta, have been proven faulty at -q0 & -q1 & produces bigger files.

I like lossywav, but I would moderate your enthousiasm, there is no way lossywav -q0 or -q1 actually beats any modern lossy codec at 256kbps transparency-wise or by quality vs. space. As far as I tested any modern lossy codec is more likely to be transparent at 256Kbps VBR than lossywav -q 0.

At -q2.5 it seems it achieves the same quality as pure lossy 256Kbps (transparency), but what you gain in transcodability you lose it in hard disk space, there is no magic. As far as I tested lossywav is not the magic codec that have all the advantage of lossless (quality) & lossy (space) ...

I see it as spreading audio bullshit ... so please people stop telling lossywav -q 0 is "almost" the same as lossless, it is definitly not. That being said I understand the enthousiasm as lossywav is the first really interesting hybrid codec IMHO. It seems a lot of people are using -q 0 thinking its quality is like -q 2.5 (transparent) ... it's not & that's exactly why it was left out of the presets. If you want an alternative to lossy 256Kbps, use -q2.5.

lossyWAV 1.1.0 Development Thread.

Reply #160 –
Quote from: halb27 on
Quote from: lvqcl on

I tried to encode "ginnungagap..." sample using lossyWAV 1.0.1k and various options.
For me, "-q 0 -m 5.333" sounds better than "-q 1" for that particular sample. Both results in 335 kbps bitrate.

Sounds like there's hope for improving the very low bitrate settings.

Well, if noise added by lossyWAV is big enough so one can hear it -- he also can hear how it changes its volume (by 6db) several times per second. And these jumps are more annoying for me than the noise itself. 

lossyWAV 1.1.0 Development Thread.

Reply #161 –
Quote from: collector on
BTW, Nick, thanks for changing the scale factor and for adding the --writelog.

All of a sudden redirecting stopped working for "lossywav --longhelp>>longhelp.txt" a few versions ago. 
Sorry - all text output now goes to "con" and not STDOUT - so that the --stdout parameter works correctly.

I'll make sure that I include the --longhelp text with each beta release at post #1.


Quote from: lvqcl on
Quote from: halb27 on
Quote from: lvqcl on
I tried to encode "ginnungagap..." sample using lossyWAV 1.0.1k and various options.
For me, "-q 0 -m 5.333" sounds better than "-q 1" for that particular sample. Both results in 335 kbps bitrate.
Sounds like there's hope for improving the very low bitrate settings.
Well, if noise added by lossyWAV is big enough so one can hear it -- he also can hear how it changes its volume (by 6db) several times per second. And these jumps are more annoying for me than the noise itself. 
Unfortunately, bits being what they are, if you round off an extra bit the noise will jump by 6dB.

My suggestion would be to use noise shaping and possibly increase --minbits from 2.333. You may also want to push --limit up to circa 17kHz.


Quote from: sauvage78 on
... I am really perplex about people telling lossywav -q0 or -q1 is a viable alternative to  any modern lossy codec at VBR 256 or 320Kbps for any use ... first using 320Kbps instead of 256Kbps even for a paranoid user is always sub-optimal, no matter the modern lossy codec 256Kbps is always a better choice than 320Kbps, 320Kbps has always been the "my-bitrate-is-higher-than-yours-so-my-files-are-better-than-yours" setting of newbies, if there would be a 321Kbps setting these knowledge-less newbies would use it anyway.
So I wouldn't compare lossywav -q 0/-q 1 to lossy 320Kbps but to lossy 256Kbps.

Now comparing any modern lossy codec at 256Kbps with lossywav -q0, you compare, heavyly tested techniques (DCT), on files that are smaller & 99.9% transparent (& even when it's not transparent, it's listenable & only ABXable by people with golden ears on specific problems samples) ... with a technique that is still beta, have been proven faulty at -q0 & -q1 & produces bigger files.

I like lossywav, but I would moderate your enthousiasm, there is no way lossywav -q0 or -q1 actually beats any modern lossy codec at 256kbps transparency-wise or by quality vs. space. As far as I tested any modern lossy codec is more likely to be transparent than lossywav -q 0.

At -q2.5 it seems it achieves the same quality as pure lossy 256Kbps (transparency), but what you gain in transcodability you lose it in hard disk space, there is no magic. As far as I tested lossywav is not the magic codec that have all the advantage of lossless (quality) & lossy (space) ...

I see it as spreading audio bullshit ... so please people stop telling lossywav -q 0 is "almost" the same as lossless, it is definitly not. That being said I understand the enthousiasm as lossywav is the first really interesting hybrid codec IMHO. It seems a lot of people are using -q 0 thinking its quality is like -q 2.5 (transparent) ... it's not & that's exactly why it was left out of the presets. If you want an alternative to lossy 256Kbps, use -q2.5.
Go and read the development thread. The lowest quality presets (also, coincidentally numerically the lowest....) are not pretending to be anything other than a lower bitrate version of the higher quality presets - but with a greater probability of artifacts. The lowest bitrate settings have always been pushed by myself and a few others who wish a lower bitrate version and are aware enough of the method not to fool themselves into thinking that the resulting files are comparable in any way to lossless.

If you don't like what lossyWAV is - it's a free world (thus far) - so don't use it.

As to "there is no way lossywav -q0 or -q1 actually beats any modern lossy codec at 256kbps transparency-wise" - have you posted your ABX logs on this one. While you're at it go searching for "killer samples" and see how other methods deal with them. Transparent at 320kbps - not always....


Quote from: The Sheep of DEATH on
I'm sorry I didn't follow this thread as closely as I would have liked, but I've observed that LossyWAV 1.01k produces significantly higher bitrates at q0 than 1.01f, which had the lowest I've seen so far and which I was quite satisfied with.  Is there any possibly of remapping the quality scale such that that the low bitrate of 1.01f is reestablished at q0?  It seems a lot like I'm going up a whole quality scale (0 to 1 or the like) from f to k with the same settings...
You could try: -q 0 -m 1.5 --spf 22222-22223-22224-12234-12345-12356 as this should revert to the previous spreading function that you were happy with and also I remember that in 1.0.1f the dynamic minimum-bits-to-keep parameter was not being applied. Have fun!

lossyWAV 1.1.0 Development Thread.

Reply #162 –
Quote from: halb27 on
Quote from: Nick.C on

Quote from: Mardel on
There is a somthing up.
I'm hearing heavily distorted sound at -q0.
Thanks for the sample, at what position in the audio are you hearing the distortion? ...

I just abxed sec. 6.4-8.6 8/10 (and I'm sure those who know this track will do better). I wouldn't call this spot heavily distorted though, but that's a matter of taste.
We know -q 0 isn't a real quality mode (though usually it's quite okay). My personal favorite for low bitrate is -q 1.5. It's not significantly higher in bitrate (312 kbps on average for my regular music test set) but to me quality does a little jump there. The spot I mentioned with your track, Mardel, is ok to me using -q 1.5.

Mardel and sauvage78, do you mind trying -q 1.5?


Hmmm.. Its really obvious and i didn't even try to abx - blocky flactuating noise @ 300 k . Its what i hear with wavpack @ 196 k . The trouble is that the track isn't very dynamic either so there could be much bigger problems for classical music. Its too dangerous (Q0) IMO for lossywav. Q0 could be a quality collapse zone.

lossyWAV 1.1.0 Development Thread.

Reply #163 –
Quote from: shadowking on
Quote from: halb27 on
Quote from: Nick.C on
Quote from: Mardel on
There is a somthing up.
I'm hearing heavily distorted sound at -q0.
Thanks for the sample, at what position in the audio are you hearing the distortion? ...
I just abxed sec. 6.4-8.6 8/10 (and I'm sure those who know this track will do better). I wouldn't call this spot heavily distorted though, but that's a matter of taste.
We know -q 0 isn't a real quality mode (though usually it's quite okay). My personal favorite for low bitrate is -q 1.5. It's not significantly higher in bitrate (312 kbps on average for my regular music test set) but to me quality does a little jump there. The spot I mentioned with your track, Mardel, is ok to me using -q 1.5.

Mardel and sauvage78, do you mind trying -q 1.5?
Hmmm.. Its really obvious and i didn't even try to abx - blocky flactuating noise @ 300 k . Its what i hear with wavpack @ 196 k . The trouble is that the track isn't very dynamic either so there could be much bigger problems for classical music. Its too dangerous (Q0) IMO for lossywav. Q0 could be a quality collapse zone.
Maybe this would be a problem that could be dealt with by using an FFT length longer than 1024 samples, or a codec-block length greater than 512 samples.

We kept the codec-block length short to specifically allow the bits-to-remove to change rapidly rather than calculating over longer blocks. This may, at -q 0, be counter productive. As David said earlier - if no artifacts are noticable at -q 0 there will be questions as to why the bitrate is not pushed lower by more aggressive settings.

As an aside, I've just finished transcoding the portion of my collection in FLAC on my server (3838 tracks, 11 days 12 hours) : 102GB, 886kbps FLAC > lossyWAV --portable / FLAC -5 -b 512: 42.1GB, 363kbps.

lossyWAV 1.1.0 Development Thread.

Reply #164 –
I've encoded that sample with wavpack 4.5b @ 235 kbit -x ABR and the quality is way better. Tried wavpack @ 196 k and I still find the quality better. Perhaps low bitrate + noiseshaping + ABR has a strength here.

Abx:

-lossywav sample - obvious - no need
- Wv 196 - obvious - no need
- Wv 235 - hiss on drum crunch 8/8 easy
- Wv 270 - can't abx

Maybe its not a fair comparison as lossywav is working way outside its quality trigger areas here while wavpack can often operate nicely even in lowish bitrates vs other hybrids (shorten, rkau, maybe losswav) as Bryant has stated once.

lossyWAV 1.1.0 Development Thread.

Reply #165 –
Quote from: shadowking on
I've encoded that sample with wavpack 4.5b @ 235 kbit -x ABR and the quality is way better. Tried wavpack @ 196 k and I still find the quality better. Perhaps low bitrate + noiseshaping + ABR has a strength here.

Maybe its not a fair comparison as lossywav is working way outside its quality trigger areas here while wavpack can often operate nicely even in lowish bitrates vs other hybrids (shorten, rkau, maybe losswav) as Bryant has stated once.
I think that this sample is one of those where the particular properties which cause lossyWAV to produce suboptimal output need to be determined, understood and mitigated. It reminds me of when we were having problems with Atem_Lied and David Bryant pointed out that the lowest bins were in the circa 200Hz area - we fixed that with the skewing parameter....

Time to get the thinking cap out again and work out this particular problem.

lossyWAV 1.1.0 Development Thread.

Reply #166 –
I've been abx fatigued for a while + a switch to linux. I've got foobar abx working with WINE and my strength is coming back so hopefully I can provide more abx input and samples. I still need to setup lossywav encoder settings etc.

lossyWAV 1.1.0 Development Thread.

Reply #167 –
@shadowking:
Yes, I think wavPack lossy does a better job below 300 kbps, as is expected from most of the usual codecs at a comparable bitrate.
I guess it's favorable in this bitrate area that wavPack lossy has a) the lossy variant integrated into the usual machinery with especially no restrictions to the blocksize and b) a dynamic noise shaping procedure which seems to work pretty well.
Moreover lossyWAV at such a low bitrate runs very much below its safe quality control mechanisms so that it's rather a miracle that it does work so relatively good.
The low bitrate settings have the advantage of being easy to test and to improve the machinery. Maybe enlarging the minimum_bits_to_keep is enough to increase the quality.

Anyway and apart from all improvement we will get hopefully I'd like to repeat my proposal for another '--low' preset which maps to 1.0.1k's -q 1.5.
It may bring down the discussion a bit on -q 0.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.1.0 Development Thread.

Reply #168 –
Sure I understand. People naturaly explore the lowest settings in any codec. Wavpack newbies probably went straight for 196 k esp non HA people, then were shocked.

lossyWAV 1.1.0 Development Thread.

Reply #169 –
Quote from: halb27 on
@shadowking:
Yes, I think wavPack lossy does a better job below 300 kbps, as is expected from most of the usual codecs at a comparable bitrate.
I guess it's favorable in this bitrate area that wavPack lossy has a) the lossy variant integrated into the usual machinery with especially no restrictions to the blocksize and b) a dynamic noise shaping procedure which seems to work pretty well.
Moreover lossyWAV at such a low bitrate runs very much below its safe quality control mechanisms so that it's rather a miracle that it does work so relatively good.
The low bitrate settings have the advantage of being easy to test and to improve the machinery. Maybe enlarging the minimum_bits_to_keep is enough to increase the quality.

Anyway and apart from all improvement we will get hopefully I'd like to repeat my proposal for another '--low' preset which maps to 1.0.1k's -q 1.5.
It may bring down the discussion a bit on -q 0.
Yes - a --lowest parameter might be a good idea. I'm going to look more closely at the detailled output for Mardel's sample (at present the --detail parameter only outputs one channel....  ). I will also have a look at implementing an optionto limit the increase in number of bits to remove between blocks (something we tried before but discounted.....).

@shadowking - your ear-time will be greatly appreciated.

lossyWAV 1.1.0 Development Thread.

Reply #170 –
Motivated by lvqcl's good experience with a higher -m value I played around a bit with my full length regular music track set:

a) bitrate increase for -m 5:

--insane:     611 kbps > 611 kbps
--extreme:  534 kbps > 534 kbps
--standard: 452 kbps > 460 kbps
--portable:  362 kbps > 385 kbps
-q 1.5:        327 kbps > 358 kbps
-q 0:           266 kbps > 332 kbps

b) bitrate increase for -m 4:

--standard: 452 kbps > 453 kbps
--portable:  362 kbps > 367 kbps
-q 1.5:        327 kbps > 334 kbps
-q 0:           266 kbps > 290 kbps

Looking at this it looks reasonable to use -m 5 for the -q settings which correspond to --insane, --extreme, and maybe --standard.
For the lower settings the bitrate penalty is a bit high though we may well reconsider the internal mappings of -q x to -nts y and -snr z in case a relatively high -m value proves to be essential.
-m 4 however IMO is appropriate also for the low bitrate settings (if we allow -q 0 to go up significantly in bitrate), and we should never use a lower -m value.

Thinking about the meaning of minimum-bits-to-keep I wonder now about the use of a very low value of ~2.5. I guess we should want to have a little bit more bits to be kept even for the lowest setting.

So I think lvqcl's listening test with a relatively high -m value (compared to what we had so far) is very valuable, and going up with -m was already taken into consideration by yourself, Nick.
lame3995o -Q1.7 --lowpass 17
 

lossyWAV 1.1.0 Development Thread.

Reply #171 –
What about mapping unsafe settings like Q0 or similar to Q 1.5 ?? Advanced users can manually use switches to get the real Q0. The lame devs did similar mappings.

lossyWAV 1.1.0 Development Thread.

Reply #172 –
Quote from: shadowking on
What about mapping unsafe settings like Q0 or similar to Q 1.5 ?? Advanced users can manually use switches to get the real Q0. The lame devs did similar mappings.
Do you mean make the "new" -q 0 aka --lowest = current -q 1.5? This would require all of the internal parameters that go to make up the preset to be available from the command line (no real problem).

or a "hidden" preset selection parameter for old -q 0? 

lossyWAV 1.1.0 Development Thread.

Reply #173 –
I guess -m 4 for -q <5, -m 5 for -q >= 5 (or a gliding -m like -m 4+0.15*q), and a --low preset which maps to -q 1.5 does it all.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.1.0 Development Thread.

Reply #174 –
I downloaded source code for 1.0.0b version.
Nick.C, can I ask you to add a new option? BTRlimit or something like this.
Then, in procedure process_this_codec_block insert one line
Code: [Select]
if min_fft_result.btr>BTRlimit then min_fft_result.btr:=BTRlimit;

just before calling remove_bits:

Code: [Select]
...
          if min_fft_result.sminbin>min_fft_result.savebin then
            fft_average:=fft_average+1
          else
            fft_minimum:=fft_minimum+1;
        end;
      end;

>>  if min_fft_result.btr>BTRlimit then min_fft_result.btr:=BTRlimit; << that line

    remove_bits;

    if (detailled_output=1) and (silent=0) then
      remove_bits_output
    else
      inc(current_codec_block);
...