GuitarFakeBook.com turns a large, inconsistent collection of Guitar Pro files into a fast, searchable chord-sheet experience built for rehearsal, practice, performance, and personal arrangement work. The interface keeps the musicianβs needs in the foreground: chords above lyrics, immediate chord-shape help, multiple playable neck positions, transpose controls, readable type, autoscroll, print, and simple song retrieval.
The product combines a lightweight browser interface with a governed source-ingestion and parsing pipeline. It preserves genuinely different arrangements, separates exact duplicates, records malformed files honestly, and converts GP3, GP4, GP5, and GPX source material into catalog and song JSON that the interface can load quickly without shipping the original source binaries to the browser.
Built for use, not demonstration. GuitarFakeBook is designed as a working tool. The system prioritizes a clean song view, playable diagrams, predictable controls, local persistence, and a recoverable source-to-output trail. AI-assisted engineering supports analysis, testing, reconciliation, and documentation, while deterministic parsers and explicit quality gates govern the musical data.
The problem behind the problem. Guitar archives may contain tens of thousands of files, duplicate bytes under different names, genuinely different versions of the same title, incomplete metadata, format-specific behavior, and chord information that is technically present but not useful in a browser without careful interpretation.
How the solution addresses it. The architecture separates archive intake, exact-byte deduplication, Guitar Pro parsing, musical reconciliation, catalog generation, interface delivery, and personal edits. Each stage produces reviewable evidence so the library can grow without losing the approved experience or hiding uncertain data.
The solution joins a musician-first interface to a controlled library-production pipeline.
GuitarFakeBook began with a straightforward product goal: make a chord sheet behave the way a guitarist expects. The approved interface centers the song, not the application chrome. Search finds an artist or title quickly; the selected song opens as a readable performance sheet; chord names sit over lyric positions; and a chord symbol reveals useful fingering choices without permanently occupying the page.
The system then extends that simple experience with the engineering required to support a real library. Multiple archive sources are inventoried, exact duplicates are identified by SHA-256 rather than filenames, source formats are parsed through one adapter, alternate arrangements are retained, and a compact generated catalog points to individual song JSON files. The browser consumes the prepared outputs rather than attempting to parse a multi-gigabyte archive during use.
The intake baseline after exact-byte comparison, before musical reconciliation and final publication.
GP3, GP4, GP5, and GPX handled by a common parser adapter and normalized output contract.
Up to 50 favorites and 50 Artistβs Den songs keep personal areas useful and bounded.
The approved HTML remains the visual and functional control while data capability is added behind it.
The interface is deliberately direct. A musician should be able to search, open, read, transpose, scroll, and play without learning a complex tool. Controls remain close to the music, visual clutter is restrained, and the same core interactions are available with mouse, keyboard, touch, and print.
A compact catalog supports title and artist retrieval, while Artistβs Den has its own separate search surface.
Chord events are anchored to lyric positions so the sheet reads like a familiar working fake book.
Chord boxes stay out of the way until the chord symbol is hovered, focused, or selected.
Transpose, type-size, autoscroll, and print controls adapt the sheet to the player and setting.
| Control | Behavior | Musician Value | Boundary |
|---|---|---|---|
| Search | Matches artist and song title against the generated catalog. | Reduces time between request and ready-to-play sheet. | Library and Artistβs Den remain separate. |
| Chord hover | Displays a six-string diagram only for the active chord symbol. | Keeps the lyric sheet clean while making help immediate. | Section labels such as [Chorus] are never treated as chords. |
| Previous / Next | Moves through verified alternative positions for the active chord. | Supports open, barre, and higher-neck choices. | Only available shapes are shown; no invented fingering. |
| Transpose | Moves chord names by semitone without rewriting lyric content. | Fits a singer, capo choice, or instrument range. | Original song JSON remains recoverable. |
| Autoscroll | Advances the song at an adjustable performance pace. | Reduces hands-on-screen interruptions. | User remains able to stop or manually reposition. |
| Backing Track | Opens a new search window using artist, title, and βbacking track.β | Moves quickly into rehearsal. | External search; no media is copied or embedded. |
| Lesson | Opens a new search window using artist, title, and βlesson.β | Connects the song directly to learning resources. | Library songs only; omitted from Artistβs Den. |
| Produces a focused paper or PDF-ready chord sheet. | Supports rehearsal rooms and stage binders. | Navigation and editing chrome are suppressed. |
The source pipeline treats every archive and extracted tree as evidence, not as a ready-made catalog. Multi-volume archives are tested with adjacent parts present. Extracted inputs are inventoried. Exact duplicate bytes are grouped before parser capacity is estimated. Raw Guitar Pro binaries remain outside the public web payload.
Validate archive integrity, volume continuity, readability, and available disk capacity before extraction.
Record relative path, extension, size, timestamp, source tree, and content hash for every candidate.
Collapse only exact-byte duplicates. Filename similarity never becomes proof that two arrangements are identical.
Normalize metadata, structure, lyrics, chord events, and diagrams through a single versioned adapter.
Compare same-title outputs. Material chord differences are retained and labeled with a simple β*altβ suffix.
Generate a small searchable index and one JSON document per usable song for lightweight delivery.
Duplicate policy. Identical SHA-256 content is one source payload regardless of naming or folder placement. Same-title files with different bytes proceed to musical comparison rather than automatic deletion.
Incomplete-data policy. A unique song without chord diagrams can still be retained when it is the only usable version. Missing fields are reported honestly and do not become fabricated musical content.
The runtime adapter uses alphaTab 1.8.4 under MPL-2.0 to read GP3, GP4, GP5, and GPX through a common interface. A normalized song contract prevents the browser from needing format-specific logic and gives quality review a stable surface.
| Normalized Field | Primary Source | Fallback / Control | Output Use |
|---|---|---|---|
| Artist | Score metadata | Folder and filename normalization | Search, grouping, and display. |
| Song title | Score metadata | Filename cleanup with preserved version cues | Catalog title and alternate naming. |
| Format | Container/header detection | Extension cross-check | Traceability and failure reporting. |
| Tuning | Selected guitar track strings | Standard tuning only when explicitly justified | Song metadata and diagram interpretation. |
| Capo | Track/score metadata | Unknown rather than guessed | Performance metadata. |
| Key | Score key signature and harmonic analysis | Reported as unknown when not defensible | Display and transpose baseline. |
| Sections | Markers and rehearsal text | Structured text recognition | Intro, Verse, Chorus, Bridge, and related labels. |
| Lyrics | Lyric-bearing events and text tracks | Reconciliation against authorized source material | Chord-over-lyric rendering. |
| Chord events | Beat-level chord/text events | Validated compact-shape parsing | Placement, transposition, and diagram lookup. |
| Diagrams | Chord definitions and string/fret data | Verified shape library when source shape is absent | Hover card and position navigation. |
Important parser controls. Bracketed section labels such as [Chorus] are classified as structure, not harmony. Compact fingering strings such as 320003 and x32010 remain six-string shapes. Multi-digit frets such as 8-10-10-9-8-8 are tokenized by string position rather than split greedily into single digits.
The chord layer is the heart of the product. It must preserve where a harmonic change occurs, name the chord correctly after transposition, and display a playable six-string form. The interface separates the compact reading view from the temporary teaching view so diagrams help without overwhelming the page.
Each event is tied to the lyric offset or musical location that caused the change.
Muted, open, fretted, and barre information is normalized into a consistent diagram model.
Players can move through multiple verified positions without changing the displayed chord name.
Unavailable diagrams remain unavailable until a controlled shape source supplies them.
GuitarFakeBook supports two kinds of user-owned state without confusing them. A player may modify an existing library song and keep that preferred version, or create a personal chord sheet in Artistβs Den. Both persist locally and can be exported, but their identifiers and schemas remain separate so one file cannot silently overwrite the other.
| Area | Purpose | Available Actions | Deliberate Exclusions |
|---|---|---|---|
| Library preferences | Remember a playerβs edited chords for an existing catalog song. | Edit chords, save locally, export preferences, import preferences, restore original. | Does not alter the canonical Git-backed song JSON. |
| Favorites | Keep a short personal list of frequently used library songs. | Click the heart or click the song in βYour Songsβ to remove; display cap of 50. | Not available for Artistβs Den songs. |
| Artistβs Den | Create and maintain personal chord sheets from a guided template. | New song, edit chords, save, search, open, delete, import, export; display cap of 50. | No favorite heart, backing-track button, lesson button, rights fields, contributor fields, or catalog metadata panel. |
Persistence behavior. Saved preferences remain in browser storage even when the user does not download a file. Export and import provide portability and recovery between sessions or devices.
Recovery behavior. Original library JSON remains separate from the preference overlay. Personal Artistβs Den records use a distinct identifier space and cannot be loaded into the library-edit path.
The build uses one approved song as the golden control before scaling to the full catalog. The control is inspected as a musician would use it and as an engineer would trace it: source identity, parser output, lyrics, sections, chord positions, diagrams, responsive behavior, persistence, print, and external search links.
Produce normalized JSON from the selected Guitar Pro source and retain source traceability.
Compare the rendered song to the approved HTML experience and the authorized lyric/control reference.
Review chord sequence, placement, sections, tuning, capo, key, and diagrams for practical usability.
Test hover, alternate positions, transpose, scrolling, font controls, editing, persistence, import/export, and print.
Set aside and document any file that fails the control rather than weakening the acceptance standard.
Run the same deterministic contract across the corpus only after the golden song passes.
The early release uses a lightweight branded PIN gate while Google sign-in remains hidden. The gate is implemented server-side in PHP with session handling, CSRF protection, rate limiting, and expiry controls. Public assets are served from Hostinger, while source control and generated catalog artifacts are governed in GitHub.
The browser does not contain the accepted PIN value or decide whether protected content is authorized.
Branches, commits, reviews, and preserved originals provide a clear path back from any failed change.
The client loads a catalog and individual songs instead of raw Guitar Pro archives.
Governance, build packets, and owner-visible artifacts remain available outside the deployed site.
The design remains deliberately lightweight. Static HTML, CSS, and browser JavaScript deliver the principal experience. PHP supplies the access boundary. Node.js performs intake and parser orchestration. Generated JSON is the contract between build-time musical processing and runtime browsing.
| Layer | Technology | Responsibility | Control |
|---|---|---|---|
| Source | RAR, GP3, GP4, GP5, GPX | Owner-maintained musical source material. | Read-only intake, archive test, and hash inventory. |
| Build | Node.js, alphaTab, SHA-256, JSON | Deduplication, parsing, normalization, reconciliation, and catalog generation. | Versioned tools, tests, manifests, and explicit failure ledger. |
| Experience | HTML5, CSS3, JavaScript | Search, song rendering, chord interaction, transpose, autoscroll, edit, print, and local preferences. | Locked visual control and responsive QA. |
| Access | PHP, sessions, CSRF controls | Branded PIN gate and protected entry. | Server-side verification, rate limiting, and expiry. |
| Delivery | GitHub, Hostinger, Apache | Version control, review, deployment, and static/runtime hosting. | Draft PR, independent review, release evidence, and rollback. |
| Personal state | Web Storage and portable JSON | Favorites, preferred edits, and Artistβs Den records. | Separate schemas, caps, validation, and original recovery. |
The product is developed under the Vantage Product Labs Build Framework V3. Each bounded task begins with a written NEXT directive, produces evidence and a return, and stops for independent REVIEW. Defects are remediated before the affected wave closes; later exploratory work does not convert an incomplete earlier gate into a pass.
Confirm repository, branch, baseline hash, source path, executor, and allowed write scope.
Perform only the bounded change with the environment capable of reaching the required assets.
Record commands, counts, hashes, screenshots, tests, failures, and exact output locations.
Compare the return against the directive, locked control, and independent acceptance criteria.
Issue one focused remediation directive when evidence exposes a defect or missing gate.
Bank the passing wave, preserve artifacts, and identify one unambiguous next action.
The architecture separates completed foundation work from the major corpus-production stage. This keeps the interface stable while parser and catalog quality are proven against real songs.
| Wave | Outcome | Acceptance Standard | State |
|---|---|---|---|
| 1 | Locked product design and embedded identity. | Approved HTML, recoverable hash, responsive baseline. | Banked |
| 2 | Core interaction and branded access gate. | Required controls work without altering locked visual intent. | Banked |
| 3 | Archive intake and exact-byte deduplication. | Integrity, manifest, duplicate ledger, and capacity evidence reconcile. | Banked |
| 4 | Parser adapter across Guitar Pro formats. | Common normalized schema and automated tests pass. | Banked |
| 5 | Golden-song reconciliation. | One approved song proves lyrics, sections, chords, diagrams, and UX behavior. | Quality gate |
| 6 | Full catalog production. | All usable songs publish; every failure and alternate reconciles. | Scale after control |
| 7 | Device branding and production hardening. | Icons, favicon, Apple assets, install metadata, security, and deployment QA pass. | Release preparation |
GuitarFakeBook combines the immediacy of a familiar chord page with the discipline required to make a large, varied source library dependable. Its success is measured less by the number of files processed than by how quickly a player can find a song, trust the changes, choose a useful shape, adapt the key, and keep personal work without damaging the source.
Searchable artist and title metadata replace manual archive browsing and filename guessing.
Chord help appears on demand, leaving the main chord-and-lyric sheet readable.
Multiple neck positions, transpose, scroll, display, print, backing tracks, and lessons support different players.
Local edits and Artistβs Den songs persist and travel through validated JSON without altering canonical data.
Peter DeCaro, currently Senior AI & Business Operations Consultant at Vantage Solutions Group, is an operations and technology-focused product builder with more than 25 years of experience improving, automating and scaling complex business operations. Across his career, he has worked for and with eight publicly traded companies and has operated at the intersection of customer operations, revenue operations, process improvement, technology implementation and organizational scale. His experience includes leadership and transformation work associated with companies including Fluent, LLC, IAC Applications, AOL and KIT Digital, as well as consulting and product-development work through Vantage Solutions Group and Vantage Product Labs.
His career has consistently centered on a practical question that now sits at the heart of MyRocket Studio: how can technology remove operational friction, create repeatable decision systems and allow people to produce better outcomes with less manual work? Long before generative AI became a mainstream operating tool, that work included process redesign, workflow automation, KPI governance, CRM and ERP implementation, customer-success operating models, vendor and workforce management, executive reporting and the rapid stabilization and scaling of growing businesses.
Peter has overseen revenue operations in excess of $50 million annually, built programs supporting customer-success and service teams of approximately 50 to 100 people, and led operational improvement initiatives across high-volume, technology-enabled organizations. His broader operating background includes large-scale customer experience environments, offshore and multi-site operations, fulfillment and service transformation, sales and revenue operations, automation, performance management and executive-level operating cadence. He is Six Sigma / Lean Six Sigma trained and has spent much of his career applying continuous-improvement principles to real operating environments rather than treating process design as an academic exercise.
In 2023, Peter was recognized by the Management and Strategy Institute (MSI) for continuous improvement, reflecting a career built around measurable operational change. That discipline has increasingly been applied to software and AI-enabled product development: translating operating problems into modular applications, measurable workflows and repeatable systems.
Most recently, through Vantage Product Labs, Peter has focused on building practical AI-enabled applications and reusable product engines. Those projects include a flight-monitoring application designed to continuously track fare changes across travel providers; ResumeRocketPro, an ATS-oriented resume analysis, scoring and optimization platform; KDP AI Secrets, a structured information-product and publishing asset creation system; and the broader MyRocket Studio / RocketCore architecture described in this document.
These products reflect a consistent operator's perspective: software should not merely generate outputβit should organize work, preserve evidence, reduce repetitive decisions, create quality controls and make the next operating cycle better than the one before it. MyRocket Studio is the culmination of that approach, combining Peter's background in operational transformation with hands-on AI-assisted product development to create a modular system for moving from market evidence to commercially testable assets and then back to measurable learning.
Peter's certifications reflect the two disciplines that converge in MyRocket Studio: formal continuous-improvement methodology and hands-on development of AI-enabled operating systems. The combination supports an operator-builder approach in which automation, process control, prompt engineering, AI agents and production application design are treated as connected capabilities rather than isolated technologies.
Project-specific additions for the Call Center Intake solution are shown first below; the complete Vantage Product Labs technology inventory from the authority document is preserved after them.
MyRocket Studio and its predecessor applications have been developed through a deliberately mixed technology stack: frontier AI models for reasoning and generation; AI-assisted development environments for implementation; structured web, database and hosting technologies for production applications; source-control and workflow systems for disciplined build management; and modular data-acquisition providers for RocketCapture and RocketIQ research workflows.
Product and company marks are shown for technology-identification purposes. Availability and use vary by product module and build stage.