BOFXV BMS package (temporary)(unofficial)
Download and extract means are the same as the previous distributing packages of BMS event.
This is immediate and will be updated from time to time.
CC BY-SA 4.0 license adopted in this blog is not applied to the link destination and packages. All copyrights belong to their respective authors.
If there is a problem, please contact us by SNS such as Twitter or Pleroma or e-mail. Especially about corrections and omissions.
At a minimum, we have modified files to fix extraction errors and complement. We don’t modify the file itself at all.
However, we are not aware of any trouble caused by the use of the following BMS package, and we are not responsible for any damage or loss caused by trouble.
You can check SHA-256 hashes with 7-Zip CRC. Select all the series of files and select CRC -> SHA-256. The upper and lower 5 digit verification should be sufficient for you.
It should contain BMS from No.001 to No.369. I don't follow it, so I don't know anything about the correction.
In other words, it includes all BMS registered in the second period.
So, the complete version was posted here.
This page will be archived.
January 13, 2020 Differential data
It should contain BMS from No.346 to No.369. I don't follow it, so I don't know anything about the correction.
I think this is probably the last.
Size: 1057171622 バイト (1008 MiB)
October 31, 2019 Differential data
It should contain BMS from No.334 to No.345. I don't follow it, so I don't know anything about the correction.
Size: 781766992 byte (745 MiB)
October 18, 2019 Differential data
It should contain BMS from No.303 to No.332. I don't follow it, so I don't know anything about the correction.
Size: 1327497729 byte (1266 MiB)
An error occurs while extracting No.321.
Playability is unconfirmed. It seems no problem:-/
October 12, 2019 Differential data
It should contain BMS from No.150 to No.301 and apply the corrections by 21:30 on October 11, 2019.
Size: 5961915604 byte (5685 MiB)
SHA256 checksum for data: DDC1BF33D588060CFBE71018C1B7FFE511A7C9367E1A3664124F4BD07C58FF8B
SHA256 checksum for data and names: C7526BA08E9DFB143506DF61B4CC97E0DE5FA0E17F360F024ADC3DE993A18618
Please delete BMS files without key sound by yourself.
October 6, 2019 Differential data
It should contain BMS from No.179 to No.200 and apply the corrections by 17:00 on October 06, 2019.
Size: 1294240670 byte (1234 MiB)
- Team Name: “強・深発酵黒烏龍茶研究所 aka 01' mega LAB” has published OGG (complete) version of “reincarnation”, so you can delete "\BOFXV\強・深発酵黒烏龍茶研究所 aka 01' mega LAB\reincarnation(WAV NO BGA)\”. However, we put the update of the old version.
October 5, 2019 initial commit
It should contain BMS from No.001 to No.178 and apply the corrections by 23:59 on October 05, 2019.
Size: 7907937137 byte (7541 MiB)
SHA256 checksum for data: 83E299D80B9B28DFAA96C21CD0A780E7D2E39050FF4C900095DF92626EB7CA3B
SHA256 checksum for data and names: 166508AF639C94BF0011216350AE9B2F3B0D3CC8EF561464FF769E8DE255330C
I initially wanted to use Git to manage BMS. But "git add ." almost killed the my EC2 instance. Is it impossible for Git to handle this scale (more than 10GB) of repository?
I don't know anything about SVN. I will try git-lfs.
When Syncthing handles a huge number of files, we needs a freak’n powerful network at first. We will go bankrupt if we use it for general distribution.
I think that Syncthing is very convenient if a small number of members use it to make a package by compressing each team. I can't (or don’t).
And let's revere wasabi.
Whatever happens, we have wasabi.
Well, here is hosted by Amazon S3.