Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user maak ! (Registered 2024-04-18) You are not logged in - nap
CSDb User Forums


Forums > CSDb Discussions > Why releasing small stuff in a whole D64 image?
2017-03-27 21:31
Hermit

Registered: May 2008
Posts: 208
Why releasing small stuff in a whole D64 image?

I'm curious why many of very small (even several kilobytes) of releases are made on .d64 image?
I'm a minimalist (usually with limited internet connection) and if I see a music or one-file demo etc. on ~170kbyte D64 I sometimes don't download it, just because I don't like the 5..10x waste of space and bandwidth in general. (And maybe the pollution it generates in big amounts, a problem nowadays I think, yet not the biggest source of pollution is IT.)

Sorry if my thinking is weird or uncommon (really hope it isn't), but I'm still curious why many people release things on .d64 instead of .prg (or .sid or .tap) if they could fit.
Is it easier to save or load D64 format on their systems or cartridges?
In any way, if you like to release small stuff in .d64, I'd thank you if you at least compress (zip) it or release a .prg beside the .d64, as seen many times, and so they won't distract people like me, and your release will be downloaded and evaluated a bit more times...
 
... 40 posts hidden. Click here to view all posts....
 
2017-03-30 17:29
Fred

Registered: Feb 2003
Posts: 284
@Hermit: I used to make T64 files for files that don't need a disk drive to preserve the filename. Then I found out that T64 files are not indexed by:

https://cbm8bit.com/8bit/commodore/search

while D64 files on CSDb are indexed so I decided to upload everything as D64 file. Since there is only one file in the D64 file, it will be highly compressed by the web server using GZIP compression when you download it so it will not cause that much extra bandwidth.

@Bugjam: please don't zip D64 files. There is really no need for it. It will not solve the bandwidth problem because that is already solved by gzip2 in the web server. It is very annoying to have C64 files in zip file format for emulators/environments that don't support it.
2017-03-30 17:36
Fred

Registered: Feb 2003
Posts: 284
Quote: i'd even go a step further - i'd want the original spread disk, unaltered. ie including whatever else was on it.

Really? We need a new release type for this: spread disk

Spread disks can be found here so I don't see any reason to dump disks on CSDb: http://scenebase.org/

But if people keep uploading full disks, we really need this release type, sight...
2017-03-30 17:51
chatGPZ

Registered: Dec 2001
Posts: 11100
no release type needed really... its just a misconception that files added to entries should be d64s that ONLY contain said release. nothing wrong with just linking the full disk to it (as has been done with tones of entries already, of course)
2017-03-30 18:54
Fred

Registered: Feb 2003
Posts: 284
Quote: no release type needed really... its just a misconception that files added to entries should be d64s that ONLY contain said release. nothing wrong with just linking the full disk to it (as has been done with tones of entries already, of course)

I think it is the other way around. It is a misconception that just full D64 files should be uploaded to entries. It doesn't make sense to me. The entry should only contain files about the release.

I think you will not like that your own entries are replaced with full disks with your release that were spread at that time, or have multiple spread disks with your demos uploaded to the same CSDb entry, do you? Just to make my point that it doesn't make sense to have full disks uploaded that contain releases not related to the entry.

How annoying it is when you want to see the release and you have to find out which file to start. You can say that it is not a big deal but for scanning tools it is.

I think that some people just upload full disks to old releases because they don't want to spend time to make a proper disk for it or they think that CSDb is about preserving disks.
2017-03-30 20:13
bugjam

Registered: Apr 2003
Posts: 2476
I agree with Groepaz here: if a release is found on a contemporary spread disk, then it is just fine and even useful to just upload the whole disk - it may contain information on the release outside of the actual file, e.g. in the dir, or through the context of other programs that it was released together with.
Very simple, very recent example: Greets to... - the release year 1988 can only be confirmed by the disk header containing the year, and the context that the group mentioned in the release was founded in 1988.
Of course there is no problem if someone wants to add a "clean" image or prg additionally.
2017-03-31 06:50
Fred

Registered: Feb 2003
Posts: 284
@Bugjam: I think you just created the solution here. If a full spread disk is uploaded because of the few cases you mentioned and the uploader also uploads a clean disk with the release only then everybody is happy.

And to come back to where this whole thread is about, this will also solves Hermit's issue of low bandwidth since D64 files with only a few files in it will cause lower bandwidth since the web server can better gzip it. So better mark the spread disk so people know what they download.
2017-03-31 12:48
chatGPZ

Registered: Dec 2001
Posts: 11100
Quote:
I think you will not like that your own entries are replaced with full disks with your release that were spread at that time, or have multiple spread disks with your demos uploaded to the same CSDb entry, do you?

yes, thats exactly what i would like to see. and i seriously hate it when ppl rip apart the disk of some crack just to create an empty d64 with one file in it and "COOLHACKERJOE" in the header. (even better: they do that using some bugged gui shit and screw up the prg even. and of course noone tests the resulting d64 either.) fucking lamers.
2017-03-31 14:54
Fred

Registered: Feb 2003
Posts: 284
Would be nice to have a separate field for a release where you can specify the scene base disk id or multiple ids so people don't have to upload spread disks. And also the ability to download the disks from the entry which means someone needs to host the files. This is a much cleaner way than uploading spread disks on CSdb.
2017-03-31 16:30
chatGPZ

Registered: Dec 2001
Posts: 11100
how is linking to a 3rd party "cleaner"?

i am not going to support all-i-want-to-do-is-doubleclick-lamers for that matter. fuckthatshit.
2017-03-31 17:55
Fred

Registered: Feb 2003
Posts: 284
Because people are now uploading releases to entries that don't belong there (I know that you totally disagree with this).

Anyway, if we keep uploading full disks, then we can better separate them from "clean" releases and then reference to it. Or separate the release downloads from spread disks downloads on the entry page so that people know what they download.

And an ability to view D64 and T64 files on CSDb would also be welcome.
Previous - 1 | 2 | 3 | 4 | 5 | 6 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
CreaMD/React
Guests online: 67
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 Wonderland XIV  (9.6)
9 The Ghost  (9.6)
10 Bromance  (9.6)
Top onefile Demos
1 It's More Fun to Com..  (9.8)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 Rainbow Connection  (9.5)
6 Wafer Demo  (9.5)
7 TRSAC, Gabber & Pebe..  (9.5)
8 Onscreen 5k  (9.5)
9 Dawnfall V1.1  (9.5)
10 Quadrants  (9.5)
Top Groups
1 Oxyron  (9.3)
2 Nostalgia  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Crackers
1 Mr. Z  (9.9)
2 S!R  (9.9)
3 Mr Zero Page  (9.8)
4 Antitrack  (9.8)
5 OTD  (9.8)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.051 sec.