Repository Analysis

tindy2013/subconverter

Utility to convert between various subscription format

2.9 Likely human-written View on GitHub

Analysis Overview

This report presents the forensic synthetic code analysis of tindy2013/subconverter, a C++ project with 16,863 GitHub stars. SynthScan v2.0 examined 70,636 lines of code across 160 source files, recording 307 pattern matches distributed across 4 syntactic categories. The overall adjusted score of 2.9 places this repository in the Likely human-written band.

The scanner applied 160+ deterministic lexical heuristics, multi-line block detectors, abstract syntax tree depth profilers, and a cross-file Jaccard similarity matrix to construct a statistically normalised synthetic code estimate. All matches are individually weighted by severity coefficient and contextual multiplier before summation, and the resulting headline score is temporally discounted to account for the repository's development history relative to the commercial emergence of large language model coding tooling (November 2022 onward).

2.9
Adjusted Score
2.9
Raw Score
100%
Time Factor
2026-07-09
Last Push
16.9K
Stars
C++
Language
70.6K
Lines of Code
160
Files
307
Pattern Hits
2026-07-14
Scan Date
0.00
HC Hit Rate

What These Metrics Mean

Adjusted Score
Primary synthetic code indicator. Raw score normalised per 1,000 lines of code and multiplied by the temporal discount factor. This is the definitive comparative metric — use it to rank repositories by AI authorship density.
Raw Score
The unmodified sum of all severity-weighted, context-multiplied pattern match scores before temporal discounting. Reflects the absolute signal strength independent of when the repository was last active.
Time Factor
The temporal discount multiplier (0–100%) applied to the raw score. Repositories last updated before ChatGPT's launch (Nov 2022) receive a 5% factor. Full signal is only assigned to repositories active in the post-adoption era (Jan 2024+).
Pattern Hits
Total count of individual pattern matches across all files and categories. A high hit count with a low score may indicate a very large codebase with isolated AI snippets; a low count with a high score indicates dense, concentrated AI signatures.
HC Hit Rate
High+Critical pattern hits per file, averaged across the repository. This orthogonal signal catches repositories where a few files are densely packed with high-severity AI tells — a strong indicator even when the normalised score appears moderate due to codebase size.
Lines of Code / Files
Total lines and files analysed. The scanner examines 94 file extensions. These denominators are used to normalise the score, enabling fair comparison between repositories of vastly different sizes.

Score History

Longitudinal tracking requires multiple scan runs. Once this repository is re-scanned after new commits land, this chart will visualise how the synthetic code signal evolves over time — enabling you to detect whether AI authorship is growing, stabilising, or being actively corrected by human engineers.

No multi-scan history yet — run the scanner again to build trend data.

Severity Breakdown

Classifies detected patterns by their diagnostic confidence and structural impact. CRITICAL patterns (coefficient 10) represent definitive synthetic signatures — hallucinated imports, explicit LLM attribution metadata — virtually never produced by human authors. HIGH (5) indicates strong structural tells such as cross-file repetition or cross-linguistic idioms. MEDIUM (2) covers recognisable conversational padding and AI-specific vocabulary. LOW (1) captures subtle indicators like tautological comments and generic boilerplate that require density to carry independent signal.

CRITICAL 0HIGH 0MEDIUM 1LOW 306

Directory Score Breakdown

This horizontal bar chart decomposes the repository's raw synthetic code score by top-level directory, allowing you to pinpoint precisely which modules or components carry the highest AI authorship density. Directories with disproportionately high scores relative to their size warrant targeted manual review: concentrated AI signatures often trace back to mass-generated configuration layers, auto-ported test suites, LLM-scaffolded boilerplate classes, or entire subsystems authored under heavy copilot assistance. Use this view to prioritise your human code-review effort.

Pattern Findings

The scanner identified 307 distinct pattern matches across 4 syntactic categories. Each entry below represents a discrete location in the source code where the engine recorded a statistically significant AI authorship indicator. Expand any category row to inspect the individual file paths, line numbers, code snippets, and the lexical context (CODE, COMMENT, or STRING) in which each match was detected.

Reading the findings table: The Severity column indicates the diagnostic confidence level (CRITICAL / HIGH / MEDIUM / LOW). The Context column identifies whether the match occurred inside executable code, an inline comment, or a string literal — comment-context matches receive a ×1.5 weight because LLMs systematically over-annotate. The ⚡ bolt icon marks clustered matches: three or more patterns within a 10-line window, each receiving an additional ×1.5 density multiplier as dense clusters constitute far stronger evidence of synthetic authorship than isolated hits.

Over-Commented Block304 hits · 201 pts
SeverityFileLineSnippetContext
LOWinclude/httplib.h1//COMMENT
LOWinclude/httplib.h21#ifndef CPPHTTPLIB_KEEPALIVE_MAX_COUNTCOMMENT
LOWinclude/httplib.h41#ifndef CPPHTTPLIB_WRITE_TIMEOUT_SECONDCOMMENT
LOWinclude/httplib.h61#ifndef CPPHTTPLIB_REQUEST_URI_MAX_LENGTHCOMMENT
LOWinclude/httplib.h81#ifndef CPPHTTPLIB_FORM_URL_ENCODED_PAYLOAD_MAX_LENGTHCOMMENT
LOWinclude/httplib.h101 : 0))COMMENT
LOWinclude/httplib.h121#ifndef _CRT_SECURE_NO_WARNINGSCOMMENT
LOWinclude/httplib.h141#endif // _MSC_VERCOMMENT
LOWinclude/httplib.h161#endifCOMMENT
LOWinclude/httplib.h181#define NI_MAXHOST 1025COMMENT
LOWinclude/httplib.h201COMMENT
LOWinclude/httplib.h221#include <iostream>COMMENT
LOWinclude/httplib.h241// these are defined in wincrypt.h and it breaks compilation if BoringSSL isCOMMENT
LOWinclude/httplib.h261#include <openssl/evp.h>COMMENT
LOWinclude/jpcre2.hpp41 * manually. In this case you will have to define `PCRE2_CODE_UNIT_WIDTH` before including `pcre2.h`.COMMENT
LOWinclude/jpcre2.hpp61//previous inclusion of pcre2.h will be respected and we won't try to include it twice.COMMENT
LOWinclude/jpcre2.hpp81 #define JPCRE2_USE_MINIMUM_CXX_17 1COMMENT
LOWinclude/jpcre2.hpp301 mcontext, replacement, rlength, outputbuffer, outlengthptr);COMMENT
LOWinclude/jpcre2.hpp361 //~ static Pcre2Type<8>::JitStack *jit_stack_create(PCRE2_SIZE startsize, PCRE2_SIZE maxsize,COMMENT
LOWinclude/jpcre2.hpp421 PCRE2_SIZE rlength,COMMENT
LOWinclude/jpcre2.hpp481 //~ Pcre2Type<16>::JitCallback callback_function,COMMENT
LOWinclude/jpcre2.hpp601 static int set_newline(Pcre2Type<32>::CompileContext *ccontext, uint32_t value){COMMENT
LOWinclude/jpcre2.hpp621 //~ }COMMENT
LOWinclude/jpcre2.hpp981 ///@param jo pointer to JPCRE2 match option that will be modified.COMMENT
LOWinclude/jpcre2.hpp1001 ///@param x whether to add or remove the modifers.COMMENT
LOWinclude/jpcre2.hpp1201//specializationCOMMENT
LOWinclude/jpcre2.hpp1221///If you want to be specific, then here's the rule:COMMENT
LOWinclude/jpcre2.hpp1241#elseCOMMENT
LOWinclude/jpcre2.hpp1261 #ifdef JPCRE2_USE_MINIMUM_CXX_11COMMENT
LOWinclude/jpcre2.hpp1321 ///@overloadCOMMENT
LOWinclude/jpcre2.hpp1501COMMENT
LOWinclude/jpcre2.hpp1521 deepMove(rm);COMMENT
LOWinclude/jpcre2.hpp1601 ///@see RegexReplace::getSubject()COMMENT
LOWinclude/jpcre2.hpp1701 return vec_ntn;COMMENT
LOWinclude/jpcre2.hpp1721 vec_num = v;COMMENT
LOWinclude/jpcre2.hpp1861 ///Set the match context.COMMENT
LOWinclude/jpcre2.hpp1881 ///User will be responsible for freeing the memory of the match data block.COMMENT
LOWinclude/jpcre2.hpp1901 /// You can get the message with RegexMatch::getErrorMessage() function.COMMENT
LOWinclude/jpcre2.hpp1921 jpcre2_match_opts = x ? jpcre2_match_opts | opt : jpcre2_match_opts & ~opt;COMMENT
LOWinclude/jpcre2.hpp1941 /// @see Regex::addModifier()COMMENT
LOWinclude/jpcre2.hpp1981 ///If you are using lambda function with capture, you must use the `std::function` approach.COMMENT
LOWinclude/jpcre2.hpp2001 /// //Examples with lambda (>=C++11)COMMENT
LOWinclude/jpcre2.hpp2021 ///This class does not allow object instantiation.COMMENT
LOWinclude/jpcre2.hpp2041 ///a MatchEvaluator object with its default constructor:COMMENT
LOWinclude/jpcre2.hpp2061 #endifCOMMENT
LOWinclude/jpcre2.hpp2081 ///COMMENT
LOWinclude/jpcre2.hpp2101 /// In such cases, previous Match data can not be used to perform a new replacment operation with this second callbaCOMMENT
LOWinclude/jpcre2.hpp2121 /// //In above, nreplace() populates jp::NumSub and jp::MapNtn with match data.COMMENT
LOWinclude/jpcre2.hpp2161 typename MatchEvaluatorCallback<void*, MapNas const &, void*>::Callback callback2;COMMENT
LOWinclude/jpcre2.hpp2281 /// .nreplace();COMMENT
LOWinclude/jpcre2.hpp2441COMMENT
LOWinclude/jpcre2.hpp2461 callback1 = mef;COMMENT
LOWinclude/jpcre2.hpp2481 ///@param mef Callback function.COMMENT
LOWinclude/jpcre2.hpp2501 ///```cppCOMMENT
LOWinclude/jpcre2.hpp2521 ///```cppCOMMENT
LOWinclude/jpcre2.hpp2541 ///@overloadCOMMENT
LOWinclude/jpcre2.hpp2561 return *this;COMMENT
LOWinclude/jpcre2.hpp2581 callback6 = mef;COMMENT
LOWinclude/jpcre2.hpp2761 ///If buffer size proves to be enough to fit the resultant stringCOMMENT
LOWinclude/jpcre2.hpp2841 ///It uses the `MatchEvaluatorCallback` function that was set with a constructor or `MatchEvaluator::setCallbackCOMMENT
244 more matches not shown…
AI Slop Vocabulary1 hit · 3 pts
SeverityFileLineSnippetContext
MEDIUMinclude/jpcre2.hpp2179 // Also, this approach proved to be more readable and robust.COMMENT
Excessive Try-Catch Wrapping1 hit · 1 pts
SeverityFileLineSnippetContext
LOWscripts/update_rules.py84 except Exception as e:CODE
Deep Nesting1 hit · 1 pts
SeverityFileLineSnippetContext
LOWscripts/update_rules.py45CODE