Thank you very much. Leela-zero is good. As I know there are many go players (either ameture or professional) who use leea-zero for training and learning.

Regards,

Jun

On Thu, Apr 1, 2021 at 3:32 PM Jonathan Roy ***@***.***> wrote:

Yes the server is offline for good, the project has ended. :)

Please check out SAI (http://sai.unich.it/) or Katago ( https://katagotraining.org/) if you'd like to contribute more to Go AI projects.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/leela-zero/leela-zero/issues/2637#issuecomment-812212312, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATP5F5PLLEBL6XJVFTBS4BDTGTYAFANCNFSM42H2VUMA .

I got the following after running AutoGTP v18, is the server down or something? AutoGTP v18 Using 1 game thread(s) per device. Starting tuning process, please wait... Network connection to server failed. NetworkException: JSON parse error: illegal value Retrying in 30 s. Network connection to server failed. NetworkException: JSON parse error: illegal value Retrying in 45 s. Network connection to server failed. NetworkException: JSON parse error: illegal value Retrying in 67 s. Maximum number of retries exceeded. Falling back to previous network.

Yes the server is offline for good, the project has ended. :)

Please check out SAI (http://sai.unich.it/) or Katago (https://katagotraining.org/) if you'd like to contribute more to Go AI projects.

I got the following after running AutoGTP v18, is the server down or something? AutoGTP v18 Using 1 game thread(s) per device. Starting tuning process, please wait... Network connection to server failed. NetworkException: JSON parse error: illegal value Retrying in 30 s. Network connection to server failed. NetworkException: JSON parse error: illegal value Retrying in 45 s. Network connection to server failed. NetworkException: JSON parse error: illegal value Retrying in 67 s. Maximum number of retries exceeded. Falling back to previous network.

Looking for the same

Signed-off-by: Doug Nazar [email protected]

Hello, I would like to ask does anyone tried to implement this in Raspberry Pi 4? Can you please help how to do it? Thank you.

Thanks for the wonderful code.

When I use command "./dump_rnn.py weights.hdf5 ../src/rnn_data.c ../src/rnn_data.h", I get a warning "warning: tensorflow: error in loading the saved optimizer state. As a result, your model is starting with a freshly initialized optimizer", will this warning effects me loaded weights correctly?

Thanks for your time.

@rillian So far the only conclusion I am able to reach is that Chrome's implementation of AudioEncoder and AudioDecoder is severely broken.

I am not sure how that API got deployed into the wild as production ready.

Even when storing the decoded chunks first, without attempting to live-stream, the output is decidedly sub-par, there is no quailty in output to speak of.

https://plnkr.co/edit/yY4CZbPNnZMT7Kwd?preview

WebCodecsAudioEncoderAudioDecoderIsBroken.zip

https://plnkr.co/edit/yY4CZbPNnZMT7Kwd?preview

Thanks for the wonderful code. In rnn_train.py file, I saw the noise_train are not be used in the training. So i wonder what is noise_train used for?

Thanks for your time.

A bug beginning in gcc version 9.2 causes strings to get incorrectly stripped when passed directly to memcmp with a zero first byte (1). This bug causes flac -t to fail on any .flac file with a md5 checksum beginning in 00. To work around this bug, the FLAC__byte type is used for an empty md5 sum to prevent a string from being stripped, which is backwards compatible and avoids compile-time checks. This was initially reported back in March 2020, but has seen more light since Ubuntu 19.10 and up ship with gcc 9.2 as the default compiler. A patch has been merged into the master gcc branch (2), but has not been included in any versions as of this commit date.

The initial reporter provided a patch in their bug report (3), which is included in this PR with authorship attributed to the reporter.

(1) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189 (2) https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=d5803b9876b3d11c93d1a10fabb3fbb1c4a14bd6 (3) https://sourceforge.net/p/flac/bugs/478/

Closes #192.

Because the compression ratio was calculated before processing the input of the last frame, it did not include the size of this last frame. This patch moves the calculation of the compression ratio after the new input has been processed. Now the compression ratio on very small files is correctly displayed.

Colnsolidated into https://github.com/xiph/flac/pull/235 .

Colnsolidated into https://github.com/xiph/flac/pull/235 .

Recently I was trying some new approaches to improve FLAC compression, when I stumbled on a possible overflow. The reason this has not come up earlier is because the encoder only hits this point when the estimate of the rice_parameter is very much off.

To trigger this overflow, one has to force rice_parameter to 0 in for example the function evaluate_lpc_subframe in libFLAC/stream_encoder.c. When encoding noisy material, which needs a high rice parameter, it can happen that the return value of that function overflows. When this happens, the wrong order might be picked, and the file blows up to enormous proportions. In my case, about 30 times the size of the original WAV file.

When analysing this problem, I found more or less the same overflow in flac/analyse.c, where in flac__analyse_frame, frame_bytes is multiplied by 8.

These patches alleviate these problems. Below two links with results

Graph with sample set 1 Graph with sample set 2

Colnsolidated into https://github.com/xiph/flac/pull/235 .

…coder_seek_absolute

In stream_decoder.c, there are three equations of finding the position in seek_to_absolute_sample_ function. The third equation i.e. when FLAC__INTEGER_ONLY_LIBRARY is defined and (upper_bound - lower_bound < 0xffffffff), can cause a divide by zero error if (upper_bound_sample - lower_bound_sample) is less than 2^16. This condition can arise due to an invalid seek table.

The fix mitigates the issue and ensures that the 1st equation and the 3rd equation give the same position under this condition.

Colnsolidated into https://github.com/xiph/flac/pull/235 .

I ran into an issue today when seeking forward or backward small amounts of samples in FLAC files without seek-tables (or with very widely spaced seek points, e.g. every 10 seconds).

Turns out the decoder always searches the whole file when seeking. That the files at hand contained a lot of silence made it worse, as it kind of defeated the pivot point calculation based on average frame size throughout the file.

This PR greatly speeds up seeking in such cases by using the current position as either the lower or upper bound, depending on where the target position happens to be.

Colnsolidated into https://github.com/xiph/flac/pull/235 .

I've been hitting this issue and I can't seem to pin down the cause:

$ flac -t 07*.flac

flac 1.3.3
Copyright (C) 2000-2009  Josh Coalson, 2011-2016  Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

07 - Natur - Flying.flac: WARNING, cannot check MD5 signature since it was unset in the STREAMINFO
ok
$ metaflac --list --block-type=STREAMINFO 07*.flac
METADATA block #0
  type: 0 (STREAMINFO)
  is last: false
  length: 34
  minimum blocksize: 4096 samples
  maximum blocksize: 4096 samples
  minimum framesize: 2031 bytes
  maximum framesize: 12721 bytes
  sample_rate: 44100 Hz
  channels: 2
  bits-per-sample: 16
  total samples: 16639640
  MD5 signature: 009e8d8af89cf3d98f748aa9383f9e90

Running checks it seems to appear in about one in two hundred files. It is present in flac v1.3.{1,2}.