HORiZON / SYNTHiC4TE / 0RGan1c / R2R

Discussion in 'Instruments' started by cloakdagger, Jan 9, 2015.

  1. cloakdagger

    cloakdagger Newbie

    Joined:
    Jan 9, 2015
    Messages:
    1
    Likes Received:
    0
    I've noticed that the best scene groups for the big instrument libraries are HORiZON vs SYNTHiC4TE and for the smaller instruments 0RGan1c and R2R are the best.

    SYNTHiC4TE library releases are always folders while HORiZON library releases are always ISO which are great because all you do is click the installer and Kontact/Kontrol auto-recognize everything. Unfortunately HORiZON releases are less abundant.

    I just downloaded Native Instruments The Gentleman v1.2 KONTAKT-HORiZON and it's awesome because it came with the pkg installer. Native.Instruments.The.Maverick.v1.2.KONTAKT-SYNTHiC4TE was just a folder so it's not quite plug & play. Still great to have for free though. Definitely not complaining.

    Does anyone know why SYNTHiC4TE can't do ISO releases like HORiZON? Is it a preference thing? A talent issue? Is HORiZON a newer group?
     
  2.  
  3. Kwissbeats

    Kwissbeats Audiosexual

    Joined:
    Mar 31, 2014
    Messages:
    1,559
    Likes Received:
    652
    I think because its a group release, the rulez state that it al shall be packed in the way they used to, otherwise it just get nuked. These guys are a bit rusty they hate changes
     
  4. OrganicSpaceRaisedMoonBeef

    OrganicSpaceRaisedMoonBeef Producer

    Joined:
    Dec 10, 2013
    Messages:
    466
    Likes Received:
    94
    Location:
    World 1, Scene 1
    Dont mistake me for being part of the scene. Im not. Just an individual who does presets and Native Instruments stuff and anything else that may appear or come this direction. Thanks for the props though.

    I dont know if Horizon is scene either. But R2R is the biggest out there i think. Or most advanced atleast.
     
  5. ArticStorm

    ArticStorm Audiosexual

    Joined:
    Jun 7, 2011
    Messages:
    7,132
    Likes Received:
    3,436
    Location:
    AudioSexPro
    nobody is scene here:
    they are not listed in the preDBs like for example prelist.ws.

    i think its personal choice that HORiZON is making ISOs and SYNTHiC4TE not.
    anyway all groups doing a great job.

    you forgot to mention T3AM HYROOOHHH with their EXTRACTED BS :rofl:
     
  6. Clandestine

    Clandestine Platinum Record

    Joined:
    Nov 11, 2013
    Messages:
    717
    Likes Received:
    151
    What this guy? :wink:

     
  7. boogiewoogie

    boogiewoogie Platinum Record

    Joined:
    Sep 15, 2012
    Messages:
    477
    Likes Received:
    196
    I Hate it when a release is in ISO with installer, much better with a ready library folder that you can just use rightaway by adding to Kontakt. Installer iso I always run on another pc, copy the installed library to an external hdd, then copy that to my daw. So much more trouble. I want to avoid running installersonmy daw if I can, less clutter in the registry.
     
  8. Mykal

    Mykal AudioP2P

    Joined:
    Jun 20, 2011
    Messages:
    1,362
    Likes Received:
    453
    Location:
    I'm Right Behind You
    First rule of Fight Club is NOT to talk about Fight Club
     
  9. SillySausage

    SillySausage Producer

    Joined:
    Jul 7, 2012
    Messages:
    2,606
    Likes Received:
    134
    Location:
    Uranus
    nothing to see here, move along please *yes*
     
  10. Mykal

    Mykal AudioP2P

    Joined:
    Jun 20, 2011
    Messages:
    1,362
    Likes Received:
    453
    Location:
    I'm Right Behind You
    I re-formatted the original NFO to ensure readability. These are the Scene rules since 2010. It should answer all of the questions that seem to pop around here.

    Introduction

    This is intended as an addendum to the existing 0day rules. All the old rules are still valid, unless they have been altered or updated by this addendum. The 0day scene has gone through major changes in this decade. As technologies have changed, so have we, but our adaptations have left many grey areas in the current rules. The last rules update was years ago when programs were much smaller and transfer speeds much lower. The existing 0day rules did not address problems of software encountered today, simply because at that date it did not exist. These changes have led to a series of loopholes which groups have been taking advantage of. The new rules we constructed aim to close these loopholes, as well as increase the general quality level of releases in the scene.

    This document covers a new ruleset for 0day. These rules and guidelines are intended for release-groups in the first place, and sites secondary. We hope that in time many sites will take over the majority of these rules. The following groups have signed and committed to following these rules:

    ACME AiR AGAiN ALiAS ARN BACKLASH BEAN BLiZZARD BRD CORE CRD CROSSFiRE DIGERATI DVT EMBRACE FALLEN FAS iNViSiBLE LND
    MESMERiZE NGEN NULL ORiON OUTLAWS RiTUEL ROGUE
    SHOCK SSG TBE UNLEASHED VACE ZWT

    These rules will go into effect starting January 31st, 2010.

    Release Name

    [Developer.name.]Program.name.vVersion[.Language][.OS][.CPU]
    [.Release.Type][.Additional.Tags]-Groupname

    Developer.Name is only mandatory if the application name is not unique enough for duping. Groups should use some common sense to keep the directory name reasonable length.

    The program name should be the official name of the application. Do not omit dashes, think of your dupe results.

    The Language tag must be used only on NON english releases. Multilingual and bilingual are optional.
    •Currently valid OS tags are:
    •Win98, WinME, WinNT, Win2k, WinXP, Win2k3, Vista, Win2k8, Win7 (can have an optional tag for more specific edition)
    •[Distribution.]Linux
    •MacOSX
    •[FreeNetOpen]BSD
    •[Open]Solaris
    •AIX
    •HPUX
    •Open.Enterprise.Server (NetWare)

    The Operating.System tag should be omitted when WinAll ( NT5 based windows and optionally earlier, always with latest official service pack). Using a UnixAll ( all of the operating systems above, excluding Windows, Linux or MacOSX) or a WinAll tag means your app *must* run on *all* of the operating systems that fall under it.

    CPU should be omitted when x86, must be x64 for x86_64/EM64T, but not IA64! Currently valid CPU tags are:
    •x86, x64, IA64, PPC, SPARC, SPARC64, RISC, Alpha

    Release.Type can be omitted for Crack/Regged, but is mandatory for keygen releases. Possible tags are:
    •Keygen.Only Keymaker.Only
    •Incl.Keygen Incl.Keymaker
    •Incl.Keygen.and.Patch Incl.Keymaker.and.Patch
    •Cracked
    •Regged

    Additional.Tags like READ.NFO, DIRFIX, NFOFIX.. must go as follows:
    •DevelopersName.ProgramName.v1.2.Regged.READ.NFO-GROUP
    •DevelopersName.ProgramName.v1.2.Regged.DIRFIX-GROUP

    You can use underscores or dots as seperator in the releasename, but do not mix them if there is no reason for it (e.g. a program name contains underscores and your seperator is a dot is a valid reason to mix)

    The lists in this section are by no means complete. They are here to serve as a guideline for proper dirname construction.

    Packaging

    Filenames must be amed up to a maximum of 8.3 characters (filename/extension). Acceptable compression format at this time is any compression method that supports multiple volumes and long file names, followed by the traditional PKZIPing. Compressions other than RAR should include an extract utility or be a self-extracting archive.

    The traditional packaging methods (zip/diz) shall be maintained, with a diz file being present in each zip. The diz file should contain as a bare minimum the number of the current disk and the maximum number of disks.

    Suggested file_id.diz layout is as follows:
    [xx/??], where ?? is the total nr of disks in the release. The total number of lines of your diz should not exceed 30.

    On a side note: using ridiculous compressions that will save 10 disks but takes 10 hours to unpack are not an acceptable solution.

    Release Size

    Allowed split volume sizes are:
    •1,444,000 bytes
    •2,888,000 bytes
    •5,000,000 bytes
    •10,000,000 bytes
    •50,000,000 bytes

    The utils disk limit is as of now 70 x 5,000,000 bytes or 35 x 10,000,000 bytes. This equates to a total of 350,000,000 bytes of compressed data. Oversize releases are allowed when no ISO release exists and the group (or an iso group they work with) is not in possession of the iso to release. In other words, there is NO size limit for 0day apps, except when an iso exists!

    The games disk limit is as of now 80 x 5,000,000 bytes or 40 x 10,000,000 bytes. This equates to a total of 400,000,000 bytes of compressed data. Any release should have less than 100 volumes. In case 10,000,000 bytes do not suffice, you are allowed to use volumes of larger size; up to 50,000,000 bytes.

    A size proper is valid when a group manages to reduce the size of the original release by at least 30 without sacrificing essential content:
    •Documentation, help files, and other non functional items can be ripped from a release to decrease size. No functional parts of an application may be ripped.
    •C++ redistributables, .NET framework, and other common operating system components may be ripped. The nfo should note what has been ripped and optionally include an url where it can be downloaded.
    •A documentation addon is only allowed if the documentation cannot be downloaded freely and publicly (without registration) from the developers website.

    Specific Release Type

    All of these releases should provide functionality identical to that of a fully licensed copy.
    •Cracked: The program file has been altered to register the program. Any nags/trial limitations should be removed. Any remnants of Trial in the app need to be removed. Any phone-home checks should be disabled!
    •Regged: Any way to make an application registered without requiring
    modification of any of the applications executables/libraries. Must include a text file with the required information, serials should not be put in the release nfo. Please name this file carefully, as to deter possible webspiders looking for serial information.
    •Keygen: A small standalone program which generates valid serials/keyfiles which are based on user input or hardware id. ◦Keygens can be written in any language but they should be native executables for the OS the application is meant for: Linux keygens for Linux applications, Mac keygens for Mac applications, etc. This means that if you do not follow this suggestion, you could get propered. However, you wont be nuked if there is no native keygen available.
    ◦A keygen that generates a system-dependant serial must explicitly warn the user of this fact, either in the nfo OR at runtime.
    ◦Windows keygens in java are allowed if the the program is coded in java or uses java. Same with any other interpreter language. If a library is included with the latest windows install, as is the case for VB6/.NET/VBScript currently, then keygens written in these languages are allowed without question. The motivation here is that a scene release should run on a clean OS install, introducing no additional dependencies other than those imposed by the application being released.
    ◦A console-based application that usually runs on headless systems (servers, etc) requires a console-based keygen.
    ◦Generic Keygens (All.Products) are allowed and dupe full releases for as long as the generic keygen continues to work for *every* application it was intended for.
    ◦Keygen.Only releases are releases that only contain the actual keygen, no installation files. They are meant as an addition to previous Crack/Regged releases.
    ◦A Keygen.and.Patch release combines a keygen with a crack to enable full functionality. You are still allowed to release a keygen.only for these releases.

    •Retail: A store-bought supply is included in this release. You are allowed to release a retail after a previous release if there is an added benefit to using the retail version. In this case you are required to add a READ.NFO tag to your dirname and list the benefits when compared to the previous release.
    •PROPER/WORKING: a proper of a previous scene-release that was not fully working should always include adequate proof and information for nukers to test and confirm the validity of the proper. This means including screenshots, pieces of code, or clear steps to reproduce the problems that occur with the release you are propering.
    •READ.NFO: If you label a release READ.NFO, please have a clearly stated section in your nfo on what the READ.NFO is all about, dont make people guess. If you want people to read it for a certain reason, make sure they can.

    Operating Systems

    If a developer has not mentioned default or minimum requirements for operating system, the default is Windows XP, which is also a minimum.

    If a program supports Windows Operating Systems before WinXP, then your crack *should* work on them aswell.

    Optional: combine multiple operating system versions for the same CPU in 1 release if it remains within size limits, for example:
    •FreeBSD5,6,7 x86 can be in a single release tagged FreeBSD
    If the installers are freely downloadable (available without registration) and the same keygen/crack works for every version, consider only including the latest version of the OS.

    Please keep in mind that the contents of .tar.gz, .rpm, .deb and any other packaging system are generally identical. Please make a note in your nfo in case of exceptions.

    Minor Updates

    MU stands for Minor Update. This term denotes an update of a previously released application within a certain time-period, the MU-period. Major updates are allowed regardless of the last time a previous version was released. In this case, the nfo should include some motivation for considering this a major update (security- and stability-critical hotfixes for instance)

    MU-period of 1 month, disregarding the number of days in a month. Examples:
    •a release on 2010-01-01 will be out of mu on 2010-02-01
    •a release on 2010-01-15 will be out of mu on 2010-02-15
    •a release on 2010-01-29 will be out of mu on 2010-02-28
    •a release on 2010-01-31 will be out of mu on 2010-02-28
    •a release on 2010-02-28 will be out of mu on 2010-03-28
    •a release on 2010-03-31 will be out of mu on 2010-04-30

    This ensures no more than a single release of the same application per month, while keeping duping simple.

    The minor update period is counted from the last valid release which contained the software itself. In other words, keymaker.only releases are not considered.

    General Rules

    If the age of the last modified file of an installed program is older than one (1) year it is not allowed to pre it without a READ.NFO or INTERNAL tag.

    A group should release the newest version of the software available. Exceptions are possible when the software is not available publicly, or if it was never released before, which *must* be mentioned in the nfo-file. This means you can release an older version of an application, but *only* if it is newer than any existing release of the same app, and you have a valid reason for not releasing the latest version (for instance, it is very hard to get the supply, or the application takes months to crack).

    There is a grace-period of 3 days: if a new version came out in the last 3 days before your release, you will not get nuked if you release the older one.

    Releases should provide the same functionality as a retail copy of the application (where possible and reasonable). Examples:
    •a virus scanner must be able to update
    •a flexlm application should include every useful feature
    •a keygen should provide either all, or the best license (watermarks are still allowed)

    Your nfo should provide a minimum of useful information, including:
    •(complete) application name
    •(complete) version, including if it is a beta version
    •the release date
    •type of crack included
    •short description of the application/game
    •description on how to use the crack (important!)
    •operating systems this release will work on
    •pre-requisites for the application/game
    •url to the applications website

    If you do not want your work to be used by other groups (be it documents, cracking methods, tools, or similar), then make sure you don't give it out to anyone you cant trust. It is deemed public property as soon as it is publicly available, and you lose any exclusive rights to it.

    Stealing cracks/keygens from P2P, WEB, or other scene groups is clearly not allowed!

    Security should be everyone's primary concern. Including nicknames or identities of people that have not given explicit permission in your nfos is absolutely not allowed, and may result in severe repercussions.
     
  11. Gramofon

    Gramofon Producer

    Joined:
    Jun 22, 2012
    Messages:
    691
    Likes Received:
    91
    Why is this in Hardware/Instruments? Was the question so urgent that you couldn't even browse through sections?
     
Loading...
Similar Threads - HORiZON SYNTHiC4TE 0RGan1c Forum Date
Elysion | Dark Horizon | Horizon Leads - By SOnuscore and Best Service Software Reviews and Tutorials Feb 23, 2024
Best Service HORIZON LEADS by Sonuscore presets and Review Software Reviews and Tutorials Feb 2, 2024
Protogon Horizon Pro by Sick Noise - 80% Off Software News Oct 16, 2022
Best Service – Dark Horizon, by Sonuscore Software Reviews and Tutorials Apr 1, 2022
Checking Out: Dark Horizon from Best Service/Sonuscore Software Reviews and Tutorials Mar 30, 2022
Loading...