This is the 19th version of Touhou Lossless Music Collection torrent, current total file size 1.75 TiB. Download and seed. If you have an older version, you can update it with (run the script in the torrent directory after stopping the old torrent but before starting new torrent). The script renames files/directories which had their names updated at some point in time - if you don't run this script you'll end up with some duplicates. As always cuesheets are located in a separate 7z archive - when extracted into the torrent directory it places cuesheets in proper places. Main torrent (7z with cues and.tta files): ( 1.65 TiB or 1 817 738 246 162 bytes). Torrent file size is 9 604 641 bytes.
Pictures torrent (cover/booklet scans): ( 76.5 GiB or 82 153 065 676 bytes). Torrent file size is 4 582 077 bytes. Supplementary materials (everything else - pdf booklets, bundled wallpapers, lyric texts, other extras): ( 24.2 GiB or 25 978 962 058 bytes). Torrent file size is 2 200 879 bytes. Additional links: Fun facts: This is the largest update to date, at about 375 GB it is almost twice as big as the whole TLMC v.01. Not so fun facts: It also took the most time.
Hif lif Downloading now- I'm looking forward to poking around and seeing what's been newly added! In late 2016 I linked you eight albums + scans via the TLMC 18 comment thread, but it looks like they didn't make it into this torrent D: Just curious, did they not meet your criteria? Here are the original comments, in case you missed them: http://www.tlmc.eu/2015/06/tlmc-v089.html?showComment=495#c583075358. Anonymous Got the thing mostly converted to Opus at my streaming site: I haven't really advertised too much, but it's like otokei which is dead. Except I'm using Opus@128kbps rather than MP3. I'd be happy if you put in the initial post like otokei was:) I still have to do about 30 or so albums manually because shnsplit doesn't like them for some reason.
Some errors I found: DiGiTAL WiNG/2013.05.26 DWCD-0008 BEST OF WiNG 例大祭10/DiGiTAL WiNG - BEST OF WiNG Special Non-Stop Version.cue This is probably the biggest one: The tta seems to be cut short. I'm missing anything pass those tracks since shnsplit errors out. N-tone/2013.08.12 NTCD-0007 FAIRY BREATH C84/CUESheet.cue Not a big one, but the filename's extension in the cue doesn't match the case sensitivity of the actual file. In the previous TLMC comments I mentioned an album with a different cue and tta name, and you said filename is in the cue anyways. I accounted for that in my script this time and there's only 7 albums that have a different name there. Also Floating Cloud/2011.12.30 FLCD-016 幻想郷事変 C81 has a tab character in track 4's name! Opus@128 This planet is not completely hopeless yet.
Good job, that's exactly what I'd choose. I still have to do about 30 or so albums manually because shnsplit doesn't like them for some reason. Try to check for single quotes, wide spaces and similar unusual stuff in filenames. At least there are no newlines:) the filename's extension in the cue doesn't match the case sensitivity of the actual file. Ah, I shouldn't have trusted foobar which followed retarded Windows 'our filenames are case-sensitive in the FS, but we'll pretend they are not' policy and happily loaded incorrect cuesheet.
Point taken, I made a script that checks for proper names and will run it before each release. Right now it sees 2 unmatched files (both because of case): N-tone/2013.08.12 NTCD-0007 FAIRY BREATH C84/FAIRY BREATH.TTA 岡垣正志&フレンズ/2011.05.01 KPCR-119S EDGE OF THE WORLD -SCARLET FANTASIA VIII- M3-27/Edge Of The World -SCARLET FANTASIA VIII.tta there's only 7 albums that have a different name there. Hm, maybe I'll just rename them for consistency then. has a tab character in track 4's name! Overall 26 instances of tabs, 9 cuesheets. Will probably update them all.
Anonymous Good job, that's exactly what I'd choose. I even redid it since the last torrent because Opus 1.2 was released in the meantime, and is supposed to be an improvement. Try to check for single quotes, wide spaces and similar unusual stuff in filenames.
At least there are no newlines:) Finally had some time to look through it, it seems to be because shnsplit doesn't recognize the audio as CD-quality: 'shnsplit: error: m:ss.ff format can only be used with CD-quality files' is the error I get. I checked the file and it's 48 kHz rather than Redbook's 44.1 kHZ. Any idea what is up with that? Some of them are: COOL&CREATE/2015.08.14 CCCD-0036 くーくり博麗フェスティバル C88/COOL&CREATE - くーくり博麗フェスティバル LiLA'c Records/2015.08.14 LLAC-0021 TOHO SPEED 04 C88/LiLA'c Records - TOHO SPEED 04. I checked the file and it's 48 kHz rather than Redbook's 44.1 kHZ. Any idea what is up with that? Probably direct mastering (without releasing a CD).
I also remember there was one 'high-def' audio in an outright insane standard: 24 bits or 96 kHz sampling freq. Or something. Started with a 'd'. I scanned the entire TLMC for outliers, there are 23+2+1+1 uncommon headers. If you switch to v19 you won't lose files per se, but you will lose some progress because of block boundary mismatch (one of questionable decisions of protocol authors to go with single stream for multifile torrents).
I think a rule of thumb is that completion of x (between 0 and 1) on older torrent will turn into completion of x^2.(newsize/oldsize) on newer torrent. Unless you're on extremely slow internet I'd recommend switching right away. You could remount volume as readonly and verify new torrent over old files to check how much progress you'd lose. Anonymous Thanks for the great work! And a few things I would like to ask: 1. As you mentioned in 'feedback request' about gluing the separate flac tracks back into one CD image. I know very little about the codec thing, but is that even possible without the rip log?
And the image you generate in this way, can it be burnt back to a CD? I ask this because I consider your reason for not using flac means that you want to keep the albums just the way they are in discs, not something we use for listening on other devices. If so, gluing the tracks back will not generate the original image, will it?
I noticed you said that you get some resources from baidu users. Does it mean that you have an access to baidu net disk share links? If so, maybe I can provide you with more resources in that way. And if not, maybe I can try to move some resources from baidu to mega if you wish? Is there a more convenient way to contact you other than commenting here? As you mentioned in 'feedback request' about gluing the separate flac tracks back into one CD image. I know very little about the codec thing, but is that even possible without the rip log?
Of course it is. You can trivially concatenate arbitrary audio files together. And the image you generate in this way, can it be burnt back to a CD? Yes, it can, CD Audio is content-agnostic. Just read the Redbook specs on wikipedia if you wish to learn the details. I ask this because I consider your reason for not using flac means that you want to keep the albums just the way they are in discs, not something we use for listening on other devices. If so, gluing the tracks back will not generate the original image, will it?
Nope, the reasons for preferring tta over flac are all there in the post. Gluing the tracks will generate something that is pretty close to the original. I noticed you said that you get some resources from baidu users. Does it mean that you have an access to baidu net disk share links? If so, maybe I can provide you with more resources in that way. And if not, maybe I can try to move some resources from baidu to mega if you wish?
Last update is 90% baidu-sourced. All my baidu links are public, so I wouldn't call that 'access'. If you have good links that I somehow missed then by all means, post them (in batches). Is there a more convenient way to contact you other than commenting here?
Commenting here is fine for me. Anonymous Gluing the tracks will generate something that is pretty close to the original. If you don't mind gluing the track, then I can do that to the resources I get and re-share them here. Will it help? Or would you like to do it yourself? Currently I have about 20 albums from Reitasai14 which are separated flac tracks and not in TLMC.
I'm still checking for the older ones. All my baidu links are public, so I wouldn't call that 'access'. So you mean that you just download from webpages and don't have any baidu account, right?
Well, downloading and sharing files between baidu accounts is much easier and less restrictive, but, never mind, public links are fine. Then I'll skip those ones.
While moving files between accounts might be faster, I'd still have to transfer them to my machine at some point. One of the most annoying thing about sharing through baidu public link is: the link can go dead easily, and once it's down, the file can never be shared again without changing its md5. And there's even some 'key words' which may lead to instant fail of sharing if they are found in the filenames(for example, '舞風', which is a circle's name). But, again, never mind that:p. Thank you for the release!
I see the.cue sheets' weight is around 20MB, so it's easy to put them in a GitLab instance for editing (I doubt we can get away with it on GitHub for copyright reasons). Did you investigate my suggestion? We can get a TLMC community project going, first for the metadata, then moving on to the rest. Right now even discussing missing albums is difficult in the comments, the 'issues' git feature would be cleaner. My fear is that we'll wait too much for a P2P silver bullet that never materializes. If we get the project started on GitLab we as a community can at least remove a bit of burden from your shoulders.
I wouldn't mind offering a VPS instance for the cause. Maybe even a Resilio (Bittorrent Sync) machine for seeding updated data+metadata. I see the.cue sheets' weight is around 20MB 10MB Did you investigate my suggestion? I answered about IPFS here We can get a TLMC community project going, first for the metadata There is an album wiki (see main post), which is fairly complete, I even used some of its album codes after double-checking with suruga-ya.
There is also vgmdb, which has less content but uses proper sql behind the scenes already. I think the easiest way to extract initial batch of metadata would be to convince either to add mass export of some sort, then to edit one could just register as user there and add changes as usual. I've finally made a plan on how to contribute to your work.
Here's the plan: 1. I've shared a folder on MEGA which contains the following files: (1) An Excel document; it's a list of all the albums I have but not in TLMC. (2) Album files; only the 'one file+cue' albums are uploaded. Considering my limited space and poor upload speed on MEGA, the separated flac tracks will not be included, perhaps you already had most of them. In case that you need some of those flac albums, their baidu links are listed in the Excel document as well. As I keep searching for missing albums in TLMC, the files in this folder will be updated gradually.
Each time I think there are already quite a lot missing albums found, I'll updated the list file and make a new post here to inform you about it. So you don't have to check this folder constantly. If you have any comments or suggestions to this plan, just tell me about it. I really hope I can help. By the way, do you know where to find nekomimi Alice's new share lists after Reitasai14? His homepage stopped updating for some reason and he has moved to some other platforms recently.
He said he would contact you soon but I haven't seen his post here yet. As I keep searching for missing albums in TLMC, the files in this folder will be updated gradually.
If you have any comments or suggestions to this plan, just tell me about it. I really hope I can help. Can you please do a csv or tab-delimited or any other plaintext format instead and stuff in into some text storage service? Here are three, github can even version-control the content: By the way, do you know where to find nekomimi Alice's new share lists after Reitasai14? His homepage stopped updating for some reason and he has moved to some other platforms recently. I don't know.
He said he would contact you soon but I haven't seen his post here yet. My chinese is limited to google translate and with that I didn't find any mentions on toholmc.
Can you please do a csv or tab-delimited or any other plaintext format instead and stuff in into some text storage service? Here are three, github can even version-control the content Sure. GitHub is fine for me. But I don't quite get your idea. You want me to post a new plain text list each time, which only contains the new missing albums I find since last post? Or keep adding to one list and post here to announce significant updates? And the album files will still stored in net disks with their links listed in the file, right?
I used an Excel file because I can order the list by different columns, and I intended to list albums from different events on different pages in order to keep each page short. But it seems that you have a different idea on how to organize the contents of the list, so I'd like to understand your opinions first. I don't know. My chinese is limited to google translate and with that I didn't find any mentions on toholmc. Well, for now, the albums of C92, Autumn Reitasai&Koromu from his project can be found here: These links can be found if you have a baidu account and subscribe him. And it is also showed on his WeChat public channel(if you know what that is). However, I think both ways are impossible for you so I've talked with him recently through instant messages.
He just said he would contact you himself so I guess maybe he will find some way to share his resources with you, or maybe he will just continue updating his homepage some day. keep adding to one list and post here to announce significant updates? And the album files will still stored in net disks with their links listed in the file, right?
I used an Excel file because I can order the list by different columns, and I intended to list albums from different events on different pages in order to keep each page short. But it seems that you have a different idea on how to organize the contents of the list, so I'd like to understand your opinions first.
You can do whatever is most convenient for you internally and then export. Actually, if it's once-a-month then don't bother, I'll use xls sheet.
I just have a bit of personal dislike for spreadsheets because they occupy a tiny niche between plaintext lists and proper databases, software to work with them is significantly more bloated than either alternative and it's a pain to set up any kind of (non-manual) I/O with them. Well, for now, the albums of C92, Autumn Reitasai&Koromu from his project can be found here: Whoa, last update could have been even bigger if I found it before.
I'll grab the files once they fix my downloader. These links can be found if you have a baidu account and subscribe him.
And it is also showed on his WeChat public channel(if you know what that is). However, I think both ways are impossible for you Yup, I have neither wechat nor baidu account. so I've talked with him recently through instant messages. He just said he would contact you himself some day. Oh, well, maybe he has his reasons.
Uh, I can't access it, something to do with private flags maybe. Well, I just checked it and noticed that my GitHub account has been flagged. I guess GitHub is not a suitable platform for sharing files which contains that many links. I'll try the other two sites you mentioned. Also, according to it could be that I permanently lost ability to download from baidu This is really bad news.
If it is really permanent, then I'll have to do the sharing in a quite different way. Currently I can think of two: 1. Move the files you need from baidu to mega. With the poor upload speed here, it may take quite a long time. And also due to the space limit, I'll have to delete the old files after you fetched them in order to put new files in when it's full. I can try to share one of my baidu accounts with you.
This is the most convenient way for you to get all the resources from baidu(including all the missing albums in the past and maybe new albums from nekomimi in the future). But I'll have to take the risk of losing that account(so I'm still hesitating in fact), and we'll have to communicate in some way other than public post here, which you may not like. What do you think then? What is your view on Musicbrainz as a platform? It's OK as it is, but I think specialized DBs are sometimes better for specialized content because 1)adding data there makes progress more visible and 2)they capture more about their subject than generic one-size-fits-all ones. I also checked right now how suitable it is for touhou in particular and the result is - not really. It does not have means to add important information such as lyricist, vocalist and 'remix-of' relation.
Could there potentially be a way to automatically send in all the TLMCs metadata Yes, if Musicbrainz has public import API and metadata is transformed into something which can be fed into it. First is likely true and second could be crudely done with cue sheet autoparsing. would it be valuable to add TLMC metadata to it? That depends on whether you use Musicbrainz or not.
I'd suggest to look at vgmdb, which is more detailed, but might lack integration with the software you use. Anonymous It does not have means to add important information such as lyricist, vocalist and 'remix-of' relation. I've been editing MusicBrainz for a while and I'd say all of these are possible, nevertheless these features are hard to notice at the first glance because the schema design of MusicBrainz is rather complicated: lyricist/vocalist apply to.recording., while 'remix-of' applies to.work. (and recording is different from track) - The MusicBrainz equivalent for 'remix-of' is 'is the basis for', see as an example.
lyrics/vocals: https://musicbrainz.org/release/8b69fe4b-c858-4c88-960e-0fbaf872c27e. Oh, I see it now. I wouldn't blame the schema, which is probably as complex as it needs to be to capture whatever they had in mind and not more. It's just invisible from the first glance at the typical album page, however it's all spelled out in the documentation pages which were one thought and a couple of clicks away.
Bad, lazy me. Musicbrainz even has ZUN game OST 'albums'/tracks (actually their length values aren't even wrong but outright undefined in conventional sense, because the tracks consist of intro and loop parts, but that's nitpicking). I read some more docs and found out they provide a dump of their DB as CC0 with edit history under BY-NC-SA, also they published server code under GPL and you can subscribe to hourly updates. I changed my mind. MusicBrainz is completely awesome and anyone thinking of contributing music metadata, TLMC or not, should just use them as.the only. worthwhile edit target (and then export if necessary).
Also, I partially retract my vgmdb recommendation because after 8 years they still keep track relationships in plaintext notes and there is still no DB dump available. Anonymous @rwx I'm the OP anon from this thread, and as somebody who spent some of my free time adding non-Touhou stuff to Musicbrainz I am really happy to have read your message from February 5th. I agree that both the way they have laid everything out in their docs and the way they are open and cooperate with archive.org is awesome. This is one of the rare occasions that I really feel like I have spread the word. I know you're just a random guy on the internet, but you seem rather competent in the few areas that I've witnessed it in, in these comments here; so maybe that's what's making it more special to me.
Or I'm just surrounded by idiots in everyday life. Anyways, yes, as you have already figured out yourself, Musicbrainz does allow for proper relationship metadata-ing. I guess a nice example is You can see CD 1 Track 23 having some not-that-often-used metadata attached, the release has Links (Discord, Amazon (ASIN attached)), catalog number, barcode, cover and is part of a series. I still think the way you're able to enter all kinds of relationships is awesome and I haven't yet found any kind of information that I haven't been able to add to the database.
Using beets.io to keep my local library in sync just adds to the awesomeness, even though it doesn't (yet) support BIN + CUE and instead focuses on per-track-files and embedded data. Since all music players of my choice (including on Android, where I use GoneMad) support BIN+CUE, I'd rather keep full albums in that format, but as it's a free software project, there is a lot that can be done about this in the long term. Spent 2 days and nights transcoding all of them to flacs.
I made a database of all included songs,and I noticed that some albums are not included. I planned to do 2 things. 1)Collecting those 'not included in TLMC ' ones, as a complement to TLMC. 2)Making a website that contains all info of all Touhou musics. Actually there is a Chinese website, thwiki.cc, already did a great job collecting musics data.
Sadly I don't know how to use a web crawler. So it might take a very long time to achieve my plan. You have a plan I've been doing for the last couple of years (recently changed my view on some things as you can read in the comment on this page by me) so I was wondering if we can combine efforts. I have been trying to fill my collection whenever TLMC was postponed, and worked out for some time but it's a high burden.
But I still intend to have a complete collection so if we can find some way to combine our strengths I think it should be possible. You can initially contact me through G+ Hangouts or on fb or additionally in my discord server: Just be sure to identify yourself, afterwards we can discuss which method of communication is the most preferred. but file name '.' Seems to be too long for windows I vaguely remember someone else complaining about this several years ago. Windows path cannot exceed 255 UCS-2 characters, however the length of this filepath is only 224 characters. The longest filepath in TLMC is 226 characters, the longest filepath overall is in supp.materials at 238 characters. As neither of these alone would fail on Windows and since they are not length outliers, I don't consider this a problem of the torrent.
Move the torrent closer to the root of your drive. BTW, i found many missing albums in xiami.com, Looks like some shit site which wants me to install phone spyware to download mp3 crap. Question 1, can I find lossless there? Question 2, do they allow free downloads? If the answer to any of these two is 'no', then it's useless. Has anyone gotten this working with rtorrent?
The previous torrents worked with my rtorrent but trying on two different boxes, I have yet to pick up any peers for this one despite waiting weeks. Also, are these magnets correct? Rtorrent rejects them and they look weirdly short - is 'magnet:?xt=urn:btih:7F2010E66FF1542E62F9C8685C9E8421D16F289E' a valid magnet? I've never seen one that short before, they usually have a domain/tracker embedded in them, I assume to serve as an introducer to the swarm. Hm, that WP doesn't really answer my question about how just a single hash would allow a torrent client to find an arbitrary IP across the Internet which has the exact torrent necessary, unless it's somehow supposed to be piggybacking on another P2P network with hardwired introducer nodes or something.
I usually have no problem in either rtorrent with DHTs or magnets ('dht = auto' is explicitly enabled in my rtorrent config as well), or with the previous TLMC torrents, and all of my Pirate Bay torrents are magnet-based & work fine, but they also all usually have some trackers embedded in them and are much longer, which is one reason I noticed, in addition to rtorrent rejecting them as invalid. That's how DHT works, I can only point to for the explanation. If one has a totally fresh client, then yes, it would need either a tracker-enabled torrent or a bootstrap node to find first peers. Then the client just caches a bunch of them. Just in case, do you have 'session' dir defined in rtorrent config? Are unencrypted connections allowed?
(Just get the copy off Nyaa, if all else fails, they probably auto-append their tracker to all uploads. Anonymous Opinions regarding feedback requests: 1. Would not support. The utility it would bring can be substituted with a text listing of mappings, and doesn't need to be in the collection itself. Plus, in situations where the circle hasn't listed an English name, there's no assurance that 1.
The one agreed upon for TLMC is certainly correct and 2. The circle won't later come out with an official English transliteration, creating another hairy rename situation. I strongly support this, though perhaps it will be best if you can come up with some way to distinguish them. With every year that passes some old content is irretrievably lost, at least to the public, and I have had the experience of searching for albums that were out of print, unavailable used, and never uploaded. TLMC is perhaps the single 'safest' repository in terms of future availability; there are already many albums for which this collection is the only accessible source, and as time goes on there will only be more such albums. Though split flacs may not be perfect representations of the CD, they are at least lossless representations of the individual tracks, and allowing albums to be lost because their format was insufficiently perfect would be a shame. Even if they were in a separate collection, it would be far better than letting them rot out of accessibility.
Anonymous This should be a top-level comment, not a reply. For circles with names in kana/kanji I looked at the circle websites. If they used an english version of the circle name then I used that as a spelling hint/alternate name in directory name: 'main name alt.name'.
The rest I've left as-is. What are your thoughts on adding alternate english names to all circles? Pros: it would make navigating directory structure and referencing circle names easier for those who don't know/are bad with kana/kanji. Cons: running rename script would be effectively mandatory, at least for that one transition, and straightforward name translation or transliteration might not mean exactly what artist intended. It would also break your existing playlists. There is a large amount of recent rips which are sadly shared as separate flac tracks with no rip logs.
For now they are not included in TLMC. What are your thoughts on gluing them back into CD images and adding those to the torrent? @gwern Yes, let's argue semantics a bit (no sarcasm implied). I think the album was still mastered in PCM by the circle and then encoded to mp3 (or whatever lossy format they used). If that's the case, then either the lossless is still there or, if they deleted it as unneeded, was there and then was lost. @Anonymous I think its OK to put it in supplementary materials.
Some mp3's which came from data portion of mixed-mode CDs are there already. The main torrent is uniform with only tta files representing CD images (and one cue sheet archive), I'd rather not create exceptions if it's one album and not one thousand.
By that logic, then almost no music has ever been released in 'lossless' format because no one simply takes the raw output of their microphones and plops it onto a CD. (Not to mention digitizing inherently analogue phenomenon in the first place.) Similarly, probably no one has ever released a proper copy of a novel because they don't include a VCS history of its activity keystroke by keystroke. And let's not even talk about movies, video games, or anything remotely complex or multimedia. The art or creation is not the bulkiest intermediate stage, but the final thing that the artist deems finished and releases. If that's a MP3 instead of a PCM, then that's the 'original' which is the highest-quality version. I did'nt find how to contact you so i write here:P here are some albums which are not included in tlmc (rip by myself, tta+cue+scan) WAVE - Symphonic Tarantella 'Lily' -幻想円舞曲 夏水仙- (download from forums, aif+scan) WAVE - Symphonic Tarantella 'Lily' -幻想円舞曲 夏水仙- WAVE - Symphonic Rhapsody Peony -交響狂詩篇 冬牡丹- https://drive.google.com/open?id=1szjg2tB-ds3jfxLS358rwg2inhNekOa. It's good to see this TLMC being updated again.
I have the previous TLMC running on which also streams opus on the native desktop client and Android client (but I still need to rewrite the site to do opus decoding as well, though that will require an extra proxy to allow the opus stream to be sent over something browsers like (currently only Opus over RTP is available)). I've been reading the comments and I finally realize why you use TTA/CUE and convinced me to change my indexer and radio software. While I used to believe that it was easier to split out TTA to FLAC so I could simply open it through libsndfile+taglib and index it into a Postgres database, I realize now that I should instead move onto File+offset and index the cue files directly and use a tta decoder library for the audio. (That's kinda the benefit of creating your own streaming software compared to pre-made ones, you can simply add your own requirements and not have the hassle of contacting the dev or get your changes merged in) I'm glad you resumed because while you postponed the previous versions, I was trying to keep up myself through doujinstyle. In the end I simply gave up on the huge amount of work. I do wonder if it would be possible to get some arrangement going on with regards to working on correcting cue files.
If you're interested discussing about it, you can write me on [email protected]. Lastly, I do wonder why you are using one giant, ever growing, torrent file instead of creating an archive of specific years. I assumed that not too many old songs will be included after a while? Or maybe this is a wrong assumption. But in my eyes, I think an old archive will not really have to be updated much since after a while all music from that period will be added. I checked, file was corrupt at the source. Source is a byte file '(例大祭10)(同人音楽)DiGiTAL WiNG BEST OF WiNG (tta+cue).rar' with sha256=d71a5f27b6b71472978e13f5de293aef2aa931ddba444472956ae5 downloaded from Archive itself tests ok, the tta fails decoding check.
It's great that already 2 people have reported this; the first time (Anonymous, 06 January, 2018 13:36) I didn't notice it for whatever reason, probably assumed it was cuesheet-related or maybe planned to check and got distracted by something. Hif lif This is a Touhou Project arrangement music collection. Here's an explanation of what Touhou is, and what Touhou arrangements sound like: When you open the torrent for the first time, you can deselect all folders, and then individually select the folders you want to download. Folders are grouped by music artist. If you like classical instrumentation, try listening to TAMUSIC (violin + piano), 街角麻婆豆 (known in English as Machikado-Mapoze; the main member uses all kinds of instruments but is especially fond of woodwind instruments like recorders), and 狐の工作室 (known as foxfactory in English; digitally-produced orchestral remixes). In general their newer albums will be more polished than their older albums, because these are amateurs slowly improving over time.
Anonymous First, you probably don't want to convert from Opus to mp3 unless you're ok with more degradation in quality. Opus and mp3 are both lossy codecs, so you should really only convert to them from a lossless source (e.g. FLAC, TTA, WAV).
In the case of Opus it will actually have to be FLAC/TTA - WAV - Opus, but you get the idea. As for supported programs, there are plenty for the desktop OSes, but I admit the options for Android are more scant.
Your best bet is probably GoneMAD music player, though it's paid and closed source. Open source apps that support Opus include Vanilla Music, AIMP, Odyssey, VLC, and probably others. But I'll admit none of these are ideal. Vanilla Music would be the best option, with its minimalism and good folder viewing, but it can't seek during Opus playback afaik.
If OTOH you have an iPhone I can't help you. Still I think it's for the best that online communities are moving from mp3 to Opus. The latter is a superior codec in every way besides compatibility, and the more we use it, the faster mobile apps will support it fully. Bug your app devs in feature requests and such. Get the word out. There are several possible reasons for that difference: - compression in general works with recognizing patterns.
So, if the file is in full, it might be able to recognize more patterns, thus compresssing better (I'm no expert on TTA, I only used libtta in my own project. I do not particularly like the library). I believe TTA requires fixed amount of audio data (one of the reasons I don't like it: it can't skip to seconds precision, it has to jump 'close enough', and forces you to skip the remainder), so it might also be due to it rounding the size to an TTA suitable size.
the complete file only has one TTA header, whereas the separate files obviously have 1 per file. This will not really add that much though So an exact 1:1 size will rarely happen. Also keep in mind that the OS might impose additional size restrictions due to the filesystem. If you want to know whether it's truly the same, you can use sound editing software like audacity to append each tta file after splitting, and comparing it to the original. In a similar manner, you could decode the individual tta's to raw wav and append that, and compare it to the full album tta decoded to raw wav. Since raw wav is uncompressed, it will have a linear relation between size and song length. (But that's probably overdoing the analysis, though it's as accurate as you can check).
Anonymous Hey rwx, what are your thoughts on keeping spaces in file/directory names? You seem very conscientious of metadata and every design decision that goes into this torrent, so I wanted your opinion. Many people advise against spaces in filenames for optimal OS interoperability and to avoid confusion in contexts such as command lines. Do you at all share this concern or do you think it is easily avoided with properly written scripts and usage of quotes and such? Or do you admit it's not ideal but the tradeoff of having ugly underscore/dash-ridden names is not worth it? Anonymous Hello!
When I try to download TLMC, it works fine for a few minutes, but after some time the download just stops and all of my bandwidth becomes dedicated to Protocol Traffic. In fact, the Protocol Traffic Download/Upload rates end up being 8x what my normal download rate would be (20MiB/s vs.
2.5 MiB/s), but it does completely halt all of my downloads and uploads. Would you happen to know if this is an issue with my client, or if this is supposed to happen, and I should just wait for it? I should also note that this has never happened before with any other torrents, including the above Pictures torrent and Supplementary Materials torrent. The downloads/uploads do continue after I restart my client (Deluge 1.3.15), but only for a few minutes before the Protocol Traffic takes over.